[jira] [Comment Edited] (OFBIZ-11007) REST: adding segmented URI support
[
https://issues.apache.org/jira/browse/OFBIZ-11007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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
[jira] [Comment Edited] (OFBIZ-11007) REST: adding segmented URI support
[
https://issues.apache.org/jira/browse/OFBIZ-11007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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
>
