Query Parameters with Values Not Matching Templates?

[cjaccino]

Pardon if I have misunderstood matching patterns. It appears that if a query parameter has a value, resolveURI() will not find its match. Is this a bug, or am I misunderstanding the expected behavior?

Thanks!

const { Router } = require('uri-template-router');
const router = new Router;
router.addTemplate('/resource{/id*}');
router.addTemplate('/resource{/id*}{?attr*}');

// URIs that successfully match
router.resolveURI("/resource/abc")
router.resolveURI("/resource/abc/def")
router.resolveURI("/resource/abc?attr")
router.resolveURI("/resource/abc?x&y")

// URIs that do not successfully match
router.resolveURI("/resource/abc?attr=1")
router.resolveURI("/resource/abc?x&y=1")

[awwright]

The query part hasn't been very well thought out, yet. Personally, I strip it out and parse it separately.

Could you please elaborate some on your use cases? That would help me improve the functionality.

[cjaccino]

What you've designed makes a lot of sense. Matching incoming calls to the closest registered URI template, returning either the a URI or a string provided during registration. From what I can see, it isn't as important that resolveURI() returns the parsed URI's elements and organizes them, just that it efficiently finds the best match. I expect that users of this software will associate multiple URI templates to a more general uri name, like the name of an OpenAPI pathItem in the paths object or the name of an operation to be routed to.

I can also see value in a wrapper function that would return an array of objects that match, ordered by match quality.

Another useful variation on resolveURI might be an option to indicate which sections of the URI template to match. A solution taking the position that the path identifies the resource, while the query merely supplements the request, might benefit from being able to ask for resource-only matches, even if the URI template itself indicates query parameters and other elements. I could also see scenarios where a solution might serve multiple domains/authorities, and it wants to see matches for the resource, regardless of which host is in the URI.

I don't see a better solution out there for matching real URIs to a set of templates.
There was quite a discussion under OpenAPI-Specification Issue 778, and it seems like you're in the position to solve some of the limitations cited there.

Thanks again.

[awwright]

@cjaccino I sent you an email (subject: URI Template Router). You caught me at a fairly good time, this is the next project I'm polishing up.

[awwright]

@cjaccino URL parameters as of now, are supported via literal pattern matching. It must be in exactly the form that would be produced by the URI Template pattern. So if you provide a template like

http://localhost/search{?q,topic}

This will match URLs like http://localhost/search?topic=bar or http://localhost/search?q=foo&topic=bar... but not http://localhost/search?topic=bar&q=foo (it's not in the expected order.)

I'm working on an option so that URL query parameters are permitted in any order (it takes the union of the variables and permits any number of those; instead of concatenating them).

Would something like that work? However this might still have unexpected effects if you do something like http://localhost/search{?q}{&topic} which would force the order.