#33780: FEATURE: add http method argument to the URLResolver
-------------------------------+------------------------------------
Reporter: abetkin | Owner: nobody
Type: New feature | Status: new
Component: Uncategorized | Version: dev
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+------------------------------------
Description changed by abetkin:
Old description:
> Hi fellows,
>
> I know the tracker is not the best place to discuss features, still here
> it is.
>
> Currently, we have URLResolver that can resolve paths. I propose that we
> add the http method as an argument, too:
> {{{
> resolver.resolve(path, method)
> }}}
>
> I think, the motivation is clear: the endpoint is actually path + http
> method. If we look at the swagger page of any API, that becomes clear. In
> the REST specification, for example, listing the items and creating new
> item have the same URL. Semantically - quite different things.
>
> Other frameworks, like Sanic or FastAPI, already support direct routing
> by http method (you can decorate the view with @app.get(your_url), so
> does Pyramid).
>
> Moreover, in the mixed wsgi + asgi application, I might want to make
> creating an item an async view (because the user should be notified about
> this event), and showing the list of item - a regular sync view. I am not
> able to do this currently.
>
> Finally: the implementation. Surprisingly, it is very simple. We just add
> an argument to URLResolver.resolve and then pass it to the recursive call
> as well. In the URLPattern we first check the http method and then call
> the super implementation. Please have a look at this gist
> [https://gist.github.com/abetkin/ba7fccedb95d656bbb77287719482e7b]
>
> In urls.py we shall be able to specify the method directly:
>
> {{{
> urlpatterns = [
> get ('items/', list_items),
> post ('items/', create_item),
> ]
> }}}
>
> In the end, I want to stress that there is NO DOWNSIDE of this
> whatsoever. It's not hard to make resolver.resolve(path) behave as it
> used to, when the method is not specified. All classes / instances remain
> the same so there will be no problems with third-party libs like
> rest_framework, swagger generators or others.
>
> Personally I am ready to contribute to this feature.
New description:
Hi fellows,
I know the tracker is not the best place to discuss features, still here
it is.
Currently, we have URLResolver that can resolve paths. I propose that we
add the http method as an argument, too:
{{{
resolver.resolve(path, method)
}}}
I think, the motivation is clear: the endpoint is actually path + http
method. If we look at the swagger page of any API, that becomes clear. In
the REST specification, for example, listing the items and creating new
item have the same URL. Semantically - quite different things.
Other frameworks, like Sanic or FastAPI, already support direct routing by
http method (you can decorate the view with @app.get(your_url)). So does
Pyramid.
Moreover, in the mixed wsgi + asgi application, I might want to make
creating an item an async view (because the user should be notified about
this event), and showing the list of item - a regular sync view. I am not
able to do this currently.
Finally: the implementation. Surprisingly, it is very simple. We just add
an argument to URLResolver.resolve and then pass it to the recursive call
as well. In the URLPattern we first check the http method and then call
the super implementation. Please have a look at this gist
[https://gist.github.com/abetkin/ba7fccedb95d656bbb77287719482e7b]
In urls.py we shall be able to specify the method directly:
{{{
urlpatterns = [
get ('items/', list_items),
post ('items/', create_item),
]
}}}
In the end, I want to stress that there is NO DOWNSIDE of this whatsoever.
It's not hard to make resolver.resolve(path) behave as it used to, when
the method is not specified. All classes / instances remain the same so
there will be no problems with third-party libs like rest_framework,
swagger generators or others.
Personally I am ready to contribute to this feature.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/33780#comment:2>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/010701815c7b4a1b-d093a9a9-36f4-4538-80dc-300288d5bf0d-000000%40eu-central-1.amazonses.com.
