Jacques,
I am working on a prototype and let you know my findings.
Thanks,
Raj
On Friday 06 May 2011 03:31 PM, Jacques Le Roux wrote:
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" <adrian.c...@sandglass-software.com>
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
