Feature Request: inverse function for resolve

[christian-bromann]

Hey there 👋

first off, thanks for all the work you've done on this package, it's awesome!

I would like to request a feature: allow to verify if a given path, e.g. /api/foobar/123 matches a pathname from the OpenAPI specification, e.g. /api/foobar/{id}. It would be the inverse to resolve.

Does this make sense?

[char0n]

Hi @christian-bromann,

first off, thanks for all the work you've done on this package, it's awesome!

Thanks a lot mate!

I would like to request a feature: allow to verify if a given path, e.g. /api/foobar/123 matches a pathname from the OpenAPI specification, e.g. /api/foobar/{id}. It would be the inverse to resolve.

I think this has broader context and might be related to overall concrete URI Reference / URL matching against the path templates. We need to design an API that would satisfy your simple usecase but would allow to do the more complex matching and handle ambiguities:

OpenAPI 3.1.0 spec reference:

From that we can inferere following predicates:

• isIdentical(pathTemplate1: string, pathTemplate2: string): boolean
• isAmbiguous(pathTemplate1: string, pathTemplate2: string): boolean

Now these predicates still don't solve your request, we need additional match function for that:

match('/pets/mine', [
 '/pets/{petId}',
 '/pets/mine'
]); => '/pets/mine'

Your case can be specialized into:

match('/pets/mine', [
 '/pets/{petId}',
]); => '/pets/{petId}'

NOTE: the function will return null if no matches are found

I have to think about this a bit more, but feel about right.

[char0n]

Started to work on this - I've introduced isIdentical predicate in #157. I'll work progressively on the matching topic and will introduce it in layers.