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