[
https://issues.apache.org/jira/browse/OFBIZ-4274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16486900#comment-16486900
]
Mathieu Lirzin commented on OFBIZ-4274:
---------------------------------------
I agree with Scott that it is better to make OFBiz _RESTFul from the ground
up_. In particular since it is already built around an HTTP API which are
defined by the various implementation of the {{EventHandler}} interface.
Given Roy Fielding's definition of resources, I think that “resources”
shouldn't be conflated with “entities”. AIUI the notion of “resource” would be
better tied to “request-map” objects because a resource is basically something
that has an URI as descibed by
[RFC-3986|https://tools.ietf.org/html/rfc3986?ref=binfind.com/web#section-1]:
{quote}This specification does not limit the scope of what might be a resource;
rather, the term "resource" is used in a general sense for whatever might be
identified by a URI. Familiar examples include an electronic document, an
image, a source of information with a consistent purpose (e.g., "today's
weather report for Los Angeles"), a service (e.g., an HTTP-to-SMS gateway), and
a collection of other resources. A resource is not necessarily accessible via
the Internet; e.g., human beings, corporations, and bound books in a library
can also be resources. Likewise, abstract concepts can be resources, such as
the operators and operands of a mathematical equation, the types of a
relationship (e.g., "parent" or "employee"), or numeric values (e.g., zero,
one, and infinity).
{quote}
Having said that, I think the POC for manipulating entities is really
interesting since the CRUD manipulations are common enough to likely generate a
lot of boiler-plate. What I would advocate however is to follow an iterative
approach by first introducing resources identified by nouns, allow the various
HTTP methods to be handled separately ({{GET/POST}} are currently mapped to the
same handler), and then define some hypermedia controls. Basically this
approach is following [Richardson maturity
model|https://www.martinfowler.com/articles/richardsonMaturityModel.html].
when we will have enough examples to start seeing patterns, we can start to
seriously think about what kind of abstractions and DSL we want when
manipulating entities more conveniently. IMHO trying to define an generic REST
model upfront is likely to make us fall into clumsy abstractions, since it is
unlikely that we could get the big picture at this stage.
Here is a concrete proposal for the first iteration:
{code:xml}
<request-map uri="examples" method="get">
<security https="true" auth="true"/>
<event type="java" path="ExamplesHandlers" invoke="getExamples"/>
<response name="success" type="view" value="..."/>
<response name="error" type="view" value="..."/>
</request-map>
<request-map uri="examples/{id}" method="get">
<security https="true" auth="true"/>
<event type="java" path="ExamplesHandlers" invoke="getExample"/>
<response name="success" type="view" value="..."/>
<response name="error" type="view" value="..."/>
</request-map>
<request-map uri="examples" method="post">
<security https="true" auth="true"/>
<event type="java" path="ExamplesHandlers" invoke="postExamples"/>
<response name="success" type="view" value="..."/>
<response name="error" type="view" value="..."/>
</request-map>
{code}
The choice for this *temporary* syntax is motivated by the fact that the only
required change in the XML grammar is an optional method attribute which
defaults to "all" to match the current behavior. To handle the {{/foo/{bar}}}
paths, the {{requestHandler::doRequest}} will resolve it by adding an extra
{{bar}} parameter associated with the matching value in the request object that
can then be retrieved in the event Handler. I have already started to implement
this. This work is accessible from [Néréide
labs|https://labs.nereide.fr/10031/Communautaire/compare/trunk...rest]
Additionally It would be interesting to be able to define a subset of requests
that the {{request-map}} handles either with a sub-element:
{code:xml}
<authorized-method><GET/><POST/></authorized-method>
{code}
or with a list of methods in the {{method}} attribute:
{code:xml}
<request-map uri="examples" method="get,post">...</request-map>
{code}
> Implement a REST Servlet
> ------------------------
>
> Key: OFBIZ-4274
> URL: https://issues.apache.org/jira/browse/OFBIZ-4274
> Project: OFBiz
> Issue Type: New Feature
> Components: framework
> Affects Versions: Trunk
> Reporter: Adrian Crum
> Priority: Major
> Labels: REST
> Attachments: RestExampleSchema.xsd, RestXmlRepresentation.xml,
> rest-conf.xml, swagger-pos-openapi.png
>
>
> Implement a REST servlet that will map REST requests to OFBiz services.
> Details are in the comments.
> [here is the discussion which took place on the dev
> ML|http://markmail.org/message/ai6q2fbksowaayn4]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
