-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Query Parameters with Values Not Matching Templates? #6
Comments
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. |
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 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. Thanks again. |
@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. |
@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
This will match URLs like 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 |
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!
The text was updated successfully, but these errors were encountered: