Conflicts in URI paths

[ChristianGruen]

As the specification indicates, conflicts may occur when many URI paths are defined. I think it would be useful to make it definite what happens in such a case. Here’s a suggestion how an implementation could proceed:

1. collect all URI paths that match a request
2. raise an error if two paths are completely identical
3. choose the most specific URI:
   1. if existing, choose the URI without parameters
   2. otherwise, choose the URI in which the first occurring parameter is specified deeper than in the other URIs
   3. check the positions of all remaining parameters in the same way

Below, all 2^3 variants for URIs for three segments are listed by their specifity:

/a/b/c
/a/b/{$x}
/a/{$x}/c
/a/{$x}/{$y}
/{$x}/b/c
/{$x}/b/{$y}
/{$x}/{$y}/c
/{$x}/{$y}/{$z}

I'm not that lucky about the wording yet; maybe it would help to map the behavior to pseudo-code. We could also check out what the JAX-RS API says about this, or how the JAX-RS Jersey implementation behaves for competing paths. – What do you think?

[ChristianGruen]

I had another look at this, and I’m now proposing the following steps:

1. First, all URI paths are collected that match the URI of the HTTP request, and all other constraints (method, consumed and produced media type).
2. The resulting paths are then sorted by their specifity:
   • Path X is more specific than path Y if it has more segments. Example: /a/b is more specific than /a.
   • If both paths have the same number of segments, the segments of both paths are compared from left to right. X is more specific than Y if the current segment of Y is a template, while the respective segment of X is not. Examples: /a/b is more specific than /a/{$x}; /a/{$x} is more specific than /{$x}/y.
3. The path with the highest specifity will be selected for further evaluation.
4. If more than one path would be returned, an error is raised. Example: the paths /a/{$x} and /a/{$y} have the same specifity, and would lead to an error.

Functions with an identical specifity will only raise an error if they have the same constraints, and are chosen as return candidates.

As a proof of concept, I have now implemented this in BaseX (works fine).

As my proposal might indicate, I’m not a native speaker, so… Feel free to revise my wording!

[ChristianGruen]

Good to know (quoted from @apb2006): “The JAX-RS solution "The request is dispatched to the first Java method in the set" see section 3.7.2 http://jsr311.java.net/nonav/releases/1.0/spec/index.html#x3-340003.7.2”

[adamretter]

Christian,

I think your second comment above is really great, and I will adopt if almost in its entirety for the spec. In eXist-db I actually implement part 1, 2a and 3 already. Part 2b is really nice though and I will certainly implement that, thanks. Regards Part 4, I think there can also be a static error as well as a dynamic error, as in some cases, when you register a Resource Function with the Service Registry, I think you can compare all known Resource Function Constraints (e.g. Paths) and find conflicts, you could then reject the registration. Of course we would need the dynamic error at Request time as well for Resource Function Constraints that are impossible to find conflicts on without looking at the Request.

[adamretter]

As this is pretty clear cut, I have added this to the TODO Wiki Page

[ChristianGruen]

Just in case: this is how I've implemented the function selection in BaseX:

https://github.com/BaseXdb/basex-api/blob/master/src/main/java/org/basex/http/restxq/RestXqModules.java#L38
https://github.com/BaseXdb/basex-api/blob/master/src/main/java/org/basex/http/restxq/RestXqPath.java#L53

All function candidates are sorted by their specifity (using Collections.sort() and compareTo() implementations in the Path class), and the first candidate is then returned if it’s the only path with that specifity.