On 12 Sep 2014, at 12:23, Christophe Demarey <Christophe.Demarey@inria.fr> wrote:

Hi Sven,

Le 12 sept. 2014 à 11:59, Sven Van Caekenberghe a écrit :

...

Hi Christophe,

On 12 Sep 2014, at 10:28, Christophe Demarey <christophe.demarey@inria.fr> wrote:

...

Hi,

I use Zinc-Rest and it works like a charm, really simple to quickly get something working. I have a question about URL pattern matching that is used to dispatch request to the right handler. I want to have following URLs: /foo/* /foo/latest I defined 2 handlers with following patterns: #('foo' '*') #('foo' 'latest')

I was expecting that the more precise handler was chosen but it was the generic handler (with '*'). Is there a way to do that? It is not blocking because I can use the same handler to manage both patterns but I would prefer to have them separated as the semantic is not the same.

Regards, Christophe.

My first answer would indeed also have been to handle both cases in one call (I did similar things in my projects). But now that you mention it, I think this can be fixed quite easily. Have a look at the following version:

=== Name: Zinc-REST-SvenVanCaekenberghe.16 Author: SvenVanCaekenberghe Time: 12 September 2014, 11:55:02.020483 am UUID: 6421d8be-c7c8-44fc-8958-121cc86ae93e Ancestors: Zinc-REST-SvenVanCaekenberghe.15

ZnCallHierarchyRestUriSpace>>#match: now uses #order to sort auto matched REST call subclasses - a lower order call will be matched before a higher order call. ===

By default, calls inherit order 50, to make move one call earlier in the matching process, override #order with a lower number.

Indeed, it does the trick with only a few changes :) I wonder if it would be a good idea to give a default lower priority (ex: 20) if the pattern ends with a '*'. It could be done in the order method. I think you will never had to override priority this way but it has a little CPU overhead.

Hmm, I thought about other ways of sorting patterns, but they will all be quite complex. [ Also remember that from a design standpoint, #pattern is not external, only #match: is, as there could be other approaches to matching ]. The trick with #order is very simple and only has to be used when there is a actual conflict, which is quite seldom I think. I can think of more conflicts than the one you can up with /tasks /tasks/* /tasks/last /tasks/*/items/* /tasks/last/items/* /tasks/*/items/last What I mean is, it is not just the number of stars. [ More like the longest match ]. But if you would come up with something general enough I would be interested. BTW, REST API design is quite hard, we have discussion about this subject here every week.

Thanks for the quick feedback. It looks like functionality on-demand :)

Christophe