nest
nest copied to clipboard
nestjs
Customizable @Method() decorator for non-standard http methods
Is there an existing issue that is already proposing this?
- [X] I have searched the existing issues
Is your feature request related to a problem? Please describe it
Extending non-standard http methods in Nest
Describe the solution you'd like
Fastify 5 has a new approach regarding non-standard http methods: https://github.com/fastify/fastify/pull/5567.
Wouldn't it be interesting to mimic this behavior within Nest?
Specifying and allowing the use of the body for each of the methods would be really interesting
Teachability, documentation, adoption, migration strategy
Have a @Method('Propfind') decorator for example and/or allow the declaration of the use of these methods at bootstrap.
What is the motivation / use case for changing the behavior?
Rather than embedding all non-standard methods in each adapter, allow these methods to be declared at startup or through the use of a special decorator.
This would allow to anticipate some requests regarding methods, including mine about webdav methods: https://github.com/nestjs/nest/pull/13278
not sure if I followed this
Can you please provide some code snippets to show us the API (or a suggestion of one) that you're thinking of?
I have one think in mind like: const Copy = HttpMethodFactory.create('COPY') and then you could use @Copy() just like any other HTTP decorators. But I don't think that this would be flexible enough to support any http adapter out there
@micalevisk I linked in the description of my proposal, the fastify implementation: https://github.com/fastify/fastify/pull/5567
I was thinking about something even more dynamic like @Method('Copy') directly from a controller. But I'm not really sure if that's realistic. I think a declaration at Nest bootstrap time might be easier to implement.
that might be feasible but we'd have to change a bunch of things including @nestjs/swagger because the support http methods are well-defined in the enum RequestMethod and the REQUEST_METHOD_MAP internal object
I like this ideia but I'm not sure if the maintenance burden is worth it nor if this aligned with the design choices that only Kamil knows.
The other solution would be to integrate all native methods supported by the http module and make them available on the express/fastify adapters. This would be much more static, no need to modify the design and that would open up possibilities within Nest.
Currently supported methods by Node :
[
'ACL', 'BIND', 'CHECKOUT',
'CONNECT', 'COPY', 'DELETE',
'GET', 'HEAD', 'LINK',
'LOCK', 'M-SEARCH', 'MERGE',
'MKACTIVITY', 'MKCALENDAR', 'MKCOL',
'MOVE', 'NOTIFY', 'OPTIONS',
'PATCH', 'POST', 'PROPFIND',
'PROPPATCH', 'PURGE', 'PUT',
'REBIND', 'REPORT', 'SEARCH',
'SOURCE', 'SUBSCRIBE', 'TRACE',
'UNBIND', 'UNLINK', 'UNLOCK',
'UNSUBSCRIBE'
]
not that flexible because we need to ensure that we're supporting any 3rd-party http adapter as well
These missing methods can be declared as optional like here: https://github.com/nestjs/nest/pull/13278/files#diff-53f40ce1eb349e4273df19efde5840940c60d6e520f569bbb35776d3894385bd
Two new specifics mapping like RequestMethod and REQUEST_METHOD_MAP but reserved to these special methods ?
Maybe not integrating non-standard http methods into third-party http adapters would also be a solution.
There is currently no easy way to use non-standard methods and it is quite restrictive :) Personally, I haven't (yet) found a way to integrate the methods that allow my webdav implementation to work under Nest (without having to build Nest on my side).
Yeah, I guess we would have to choose between adding more methods that would be optional to avoid breaking changes, or making the http adapter flexible enough to support any http method
Personally I prefer fastify's approach
https://github.com/nestjs/nest/pull/13278 has been merged and will be published as part of the v11 release.
We don't plan to add the customizable @Method() decorator though (it was available in v6 a few years ago and we eventually dropped it).
