http://ofbiz.116.s1.nabble.com/Discussion-REST-support-in-OFBiz-tp3497127p3498522.html
> 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
>>>>
>>
>