[jira] [Comment Edited] (OFBIZ-11007) REST: adding segmented URI support

["Mathieu Lirzin (Jira)" <ji...@apache.org>]

    [ 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/29/19 2:58 PM:
------------------------------------------------------------------

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)