feat(http/unstable): add capability to attach handlers by methods, implement sensible defaults #6305
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi everyone!
I would like to propose a new implementation of the
route()
function that adds the capability to define handlers on a per-method basis (in a style similar to Fresh) or to use a single handler that handles all methods.I envision the
route()
function being used only once when we pass it toDeno.serve()
. In the case of a REST API, one would:user.ts
with URL patterns such as/api/users
and/api/users/:id
.products.ts
with URL patterns such as/api/products
and/api/products/:id
.main.ts
, then callDeno.serve(route([...userRoutes, ...productRoutes, notFoundRoute], errorHandler))
.The current
defaultHandler()
does not seem very useful, as a wildcard route can provide the same functionality (see tests). I believe an optionalerrorHandler()
would be more important.While my PR adds some logic to the
route()
function, it conforms to the relevant specifications (RFC2616) and practices regarding the "Method Not Allowed" response, error handling, and the default "Not Found" response, at least to my understanding. Furthermore, all of the new default behavior remains customizable by the user.Accepting this PR in its current form would essentially mean that the
URLPattern
would be the only factor determining whether a Route can handle the request or not.