ofbiz-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mathieu Lirzin (Jira)" <j...@apache.org>
Subject [jira] [Comment Edited] (OFBIZ-11007) REST: adding segmented URI support
Date Mon, 30 Dec 2019 08:30:00 GMT

    [ https://issues.apache.org/jira/browse/OFBIZ-11007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17004807#comment-17004807
] 

Mathieu Lirzin edited comment on OFBIZ-11007 at 12/30/19 8:30 AM:
------------------------------------------------------------------

Hello [~nmalin],

The approach we followed with [~artemiy] was to intentionally not provide any guarantee on
the request-map resolution algorithm in the context of ambiguities, meaning when multiple
request-maps are matching the same HTTP request URI. Our assumption was that ambiguous routes
should not be used to simplify reasoning/debugging. A limitation of the current implementation
is that we currently don't detect/report those ambiguities, we simply choose one.

Our approach is debatable and for example the JAX-RS specification which serves as a standard
for Java REST APIs [specifies a precedence order when matching URI|https://download.oracle.com/otn-pub/jcp/jaxrs-2_1-final-eval-spec/jaxrs-2_1-final-spec.pdf?AuthParam=1577630576_4b24b6231d72cf225332a21ec2aaf761#subsection.3.7.2].
So I am not strongly opposed to specifying a resolution order in OFBiz as you proposed in
[^OFBIZ-11007_refactor-entitymaint.patch], with the condition that it follows a standard and
documented algorithm like for example the one from JAX-RS.

Regarding the particular case of entities, a simple way to avoid ambiguities in your example
would be to use different separators like for example:
{code:java}
    entity-list -> entitymaint
    entity/{entityName} -> FindGeneric
    entity/{entityName}/{pkValues: .*} -> ViewGeneric 
    entity-edit/{entityName} -> edit form
    entity-edit/{entityName}/{pkValues: .*} -> edit form
    entity-relations/{entityName} -> ViewRelation
{code}
If you really want to use {{/}} while removing ambiguities you can use regular expression
in URI templates to prevent {{entity/\{entityName\}}} to match {{/entity/list}} you should
be able to replace it with something like {{entity/\{name: (?!list).*\}}} to prevent the match
(not tested). However I don't recommend that solution because it requires understanding an
advanced feature of Java regexp.

Thanks for working on that.


was (Author: mthl):
Hello [~nmalin],

The approach we followed with [~artemiy] was to intentionally not provide any guarantee on
the request-map resolution algorithm in the context of ambiguities, meaning when multiple
request-maps are matching the same HTTP request URI. Our assumption was that ambiguous routes
should not be used to simplify reasoning/debugging. A limitation of the current implementation
is that we currently don't detect/report those ambiguities, we simply choose one.

Our approach is debatable and for example the JAX-RS specification which serves as a standard
for Java REST APIs [specifies a precedence order when matching URI|https://download.oracle.com/otn-pub/jcp/jaxrs-2_1-final-eval-spec/jaxrs-2_1-final-spec.pdf?AuthParam=1577630576_4b24b6231d72cf225332a21ec2aaf761#subsection.3.7.2].
So I am not strongly opposed to specifying a resolution order in OFBiz as you proposed in
[^OFBIZ-11007_refactor-entitymaint.patch], with the condition that it follows a standard and
documented algorithm like for example the one from JAX-RS.

Regarding the particular case of entities, a simple way to avoid ambiguities in your example
would be to use different separators like for example:
{code:java}
    entity-list -> entitymaint
    entity/{entityName} -> FindGeneric
    entity/{entityName}/{pkValues: .*} -> ViewGeneric 
    entity-edit/{entityName} -> edit form
    entity-edit/{entityName}/{pkValues: .*} -> edit form
    entity-relations/{entityName} -> ViewRelation
{code}
If you really want to use {{/}} while removing ambiguities you can use regular expression
in URI templates to prevent {{entity/\{entityName\}}} to match {{/entity/list}} you should
be able to replace it with something like {{entity/\{name:(?!list).*\}}} to prevent the match
(not tested). However I don't recommend that solution because it requires understanding an
advanced feature of Java regexp.

Thanks for working on that.

> REST: adding segmented URI support
> ----------------------------------
>
>                 Key: OFBIZ-11007
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-11007
>             Project: OFBiz
>          Issue Type: New Feature
>          Components: framework
>    Affects Versions: Trunk
>         Environment: 
>            Reporter: Artemiy Rozovyk
>            Assignee: Nicolas Malin
>            Priority: Minor
>              Labels: REST, URI
>             Fix For: Upcoming Branch
>
>         Attachments: OFBIZ-11007_refactor-entitymaint.patch, OFBIZ-11007_refactor-entitymaint.patch,
entitymaint_example.patch, restful_URIs.patch
>
>
> Following the discussion on making OFBiz RESTful OFBIZ-4274 i implemented the support
of segmented URIs without interfering with current mechanisms of URI resolution nor with 
_overrideView()_ feature.
> Combined with work on associating URIs and HTTP methods done by [~mthl] in OFBIZ-10438
, we are now able to provide RESTful APIs as follows:
> {code:java}
> <request-map uri="foo/bar" method="get">
> ...
> <request-map uri="foo/bar/{baz}" method="get">
> ...
> <request-map uri="foo/bar/{baz}" method="post">
> ...
> {code}
> After we matched a request-map having parametrized URI as in 
> {code:java}
> uri="foo/bar/{baz}"
> {code}
> the value is available inside the request attributes with the corresponding key (here
_"baz"_)
> The *restful_URIs.patch* allows segmented URI support.
> The *entitymaint_example.patch* is a modified _entitymaint_ part that serves as an example
of possible application of new system. 
> Any questions or comments are welcomed.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Mime
View raw message