Address Issue #751 by using method mismatch flag in Route.Match()
The flag allows Route.Match() to return MethodNotAllowed (405) from an earlier mismatch instead of returning NotFound (404) from a later mismatch (refer to example from #751).
The following results show some edge cases:
PUT /v1/foo?id=1 returns 405 (match second endpoint, desired behavior)
GET /v1/foo?id=abc returns 404 (match second endpoint, 400 on second endpoint preferred)
POST /v1/foo?id=abc returns 200 (match first endpoint, 405 on second endpoint might be preferred)
POST /v1/foo?id=1 returns 200 (match first endpoint, 405 on second endpoint might be preferred)
PUT /v1/foo returns 404 (match second endpoint, 405 on first endpoint preferred)
GET /v1/foo returns 404 (match second endpoint, 400 on first or 405 on second preferred)
These edge cases can be partially resolved(?) by declaring endpoints in descending order of specificity.
PUT /v1/foo?id=1 returns 405 (match first endpoint, desired behavior)
GET /v1/foo?id=abc returns 405 (match second endpoint, 400 on first endpoint preferred)
POST /v1/foo?id=abc returns 200 (match second endpoint, 405 on first endpoint might be preferred)
POST /v1/foo?id=1 returns 200 (match second endpoint, 405 on first endpoint might be preferred)
PUT /v1/foo returns 405 (match second endpoint, desired behavior)
GET /v1/foo returns 405 (match second endpoint, 400 on first endpoint might be preferred)
NOTE:might be is a soft suggestion
Related Tickets & Documents
Related Issue #
Closes #
Added/updated tests?
[ ] Yes
[x] No, and this is why: existing test already tests this and passes, but, for an unknown reason, when using the package (by importing, not within the package), the test fails.
What type of PR is this? (check all applicable)
Description
Address Issue #751 by using method mismatch flag in
Route.Match()
The flag allows
Route.Match()
to returnMethodNotAllowed (405)
from an earlier mismatch instead of returningNotFound (404)
from a later mismatch (refer to example from #751).For nested endpoints,
The following results show some edge cases:
PUT /v1/foo?id=1
returns405
(match second endpoint, desired behavior)GET /v1/foo?id=abc
returns404
(match second endpoint, 400 on second endpoint preferred)POST /v1/foo?id=abc
returns200
(match first endpoint, 405 on second endpoint might be preferred)POST /v1/foo?id=1
returns200
(match first endpoint, 405 on second endpoint might be preferred)PUT /v1/foo
returns404
(match second endpoint, 405 on first endpoint preferred)GET /v1/foo
returns404
(match second endpoint, 400 on first or 405 on second preferred)These edge cases can be partially resolved(?) by declaring endpoints in descending order of specificity.
PUT /v1/foo?id=1
returns405
(match first endpoint, desired behavior)GET /v1/foo?id=abc
returns405
(match second endpoint, 400 on first endpoint preferred)POST /v1/foo?id=abc
returns200
(match second endpoint, 405 on first endpoint might be preferred)POST /v1/foo?id=1
returns200
(match second endpoint, 405 on first endpoint might be preferred)PUT /v1/foo
returns405
(match second endpoint, desired behavior)GET /v1/foo
returns405
(match second endpoint, 400 on first endpoint might be preferred)Related Tickets & Documents
Added/updated tests?
Run verifications and test
make verify
is passingmake test
is passing