http://ofbiz.116.s1.nabble.com/Discussion-REST-support-in-OFBiz-tp3497127p3502047.html
> Raj,
>
> How do you picture Apache CXF being used in OFBiz? How would we map REST
> requests to OFBiz services using CXF?
>
> -Adrian
>
>
> On 5/4/2011 9:48 PM, Raj Saini wrote:
>> There is also JAX-RS Java API (
http://en.wikipedia.org/wiki/JAX-RS). I
>> believe integrating current implementation such as Apache CXF similar
>> to the way Axis is integrated for SOAP based web services should be
>> less work than doing it all ourselves.
>>
>> Thanks,
>>
>> Raj
>>
>> On Thursday 05 May 2011 06:54 AM, Adrian Crum wrote:
>>> Thanks Scott!
>>>
>>> I agree - the REST URLs (or URIs) should represent resources and the
>>> HTTP commands should represent actions taken on those resources. I
>>> guess I was trying to take a shortcut by having REST URLs point
>>> directly to OFBiz services.
>>>
>>> So we need a way to map REST URLs to the appropriate services. Maybe
>>> the service definitions could include a REST resource identifier.
>>> That should be easy to implement.
>>>
>>> How could we implement something like the "Link things together"
>>> section of this article:
>>>
>>>
http://www.infoq.com/articles/rest-introduction>>>
>>> (That question is for the community, not Scott specifically).
>>>
>>> -Adrian
>>>
>>>
>>> On 5/4/2011 5:54 PM, Scott Gray wrote:
>>>> Hi Adrian
>>>>
>>>> My limited understanding is that RESTful URLs should point to a data
>>>> resource rather than service logic resources. The verbs (HTTP
>>>> request method) are used to indicate the type of operation (CRUD) to
>>>> be performed on the noun (data object). So you'd have something
>>>> like a URL that points to say the "person" resource and using that
>>>> URL you can GET a person(s), create or update (POST) a person(s) and
>>>> DELETE a person.
>>>>
>>>> If what I say above is correct then what OFBiz lacks primarily is
>>>> the ability to map a verb and nouns combination to a specific
>>>> service. I believe David has taken some steps to resolving that in
>>>> Moqui which we could achieve by altering the way we define services
>>>> or alternatively as a stop-gap measure we could introduce an
>>>> additional mapping layer which defines resource end-points and maps
>>>> the request type to the appropriate service (perhaps not so easy for
>>>> POST operations that use a create or update approach but possible by
>>>> checking for the presence of specific record identifying parameters
>>>> to indicate an update).
>>>>
>>>> What you've described below sounds more like a regular HTTP web
>>>> service approach that just makes a bit more use of the request
>>>> headers than we do currently.
>>>>
>>>> Regards
>>>> Scott
>>>>
>>>> HotWax Media
>>>>
http://www.hotwaxmedia.com>>>>
>>>> On 5/05/2011, at 12:11 PM, Adrian Crum wrote:
>>>>
>>>>> I'm working on a project that might require accessing OFBiz
>>>>> services via REST. I know there have been discussions about using
>>>>> Axis, and Chris Snow was able to get a REST library to work with
>>>>> OFBiz. Please correct me if I'm wrong, but it seems to me OFBiz
>>>>> already has most of what is needed to implement REST, so there
>>>>> shouldn't be any need to use any additional libraries.
>>>>>
>>>>> From what I understand, REST services are simply HTTP requests
>>>>> sent to a particular URL to invoke a particular service. The
>>>>> request response contains any requested data in a format the REST
>>>>> client specified in the request. The HTTP commands GET, POST, PUT,
>>>>> and DELETE are used in the requests. The meaning of the REST HTTP
>>>>> commands are server-specific.
>>>>>
>>>>> So here is what I'm thinking: Let's say we want to access OFBiz
>>>>> services via REST. We don't need to support the PUT and DELETE
>>>>> commands because the services themselves determine what actions
>>>>> will be performed on the data. So, let's say that a GET command
>>>>> gets information about the service, and the POST command invokes
>>>>> the service.
>>>>>
>>>>> From my perspective, this could be implemented in two different
>>>>> ways: a REST servlet or a REST view handler. In either case, the
>>>>> basic flow would be something like:
>>>>>
>>>>> 1. Get service name from request URL, look up service model. If
>>>>> export is false, return 404.
>>>>> 2. If service model auth is true, get credentials from HTTP header.
>>>>> If no credentials, return 401. If credentials are found, attempt to
>>>>> log in user. If login fails, return 401.
>>>>> 3. If command is GET, get Accept content type(s) from HTTP header,
>>>>> use those to find a converter. Convert service model info to
>>>>> requested type and put it in the response.
>>>>> 4. If command is POST, get content type from HTTP header, use that
>>>>> to find a converter. Convert POST data to service parameters and
>>>>> invoke the service. Get Accept content type(s) from HTTP header,
>>>>> use those to find a converter. Convert service result to requested
>>>>> type and put it in the response.
>>>>>
>>>>> So, we could implement REST with existing artifacts - no additional
>>>>> libraries are needed (except maybe for data conversions).
>>>>>
>>>>> What do you think? I'm not a REST expert, so comments are welcome!
>>>>>
>>>>> -Adrian
>>>>>
>>>
>>