http://ofbiz.116.s1.nabble.com/Discussion-REST-support-in-OFBiz-tp3497127p3502261.html
> IIRW CXF uses Java annotations, is this not limiting us (simple-methods)?
> Raj did you think about an engine part of CXF to include in OFBiz?
>
> Jacques
>
> From: "Adrian Crum" <
[hidden email]>
>> 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
>>>>>>
>>>>
>>>
>
>