[ 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)