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