[Django] #33780: FEATURE: add http method argument to the URLResolver
Django
-----------------------------------------+------------------------
Reporter: abetkin | Owner: nobody
Type: Uncategorized | Status: new
Component: Uncategorized | Version: 4.0
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-----------------------------------------+------------------------
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>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
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
Changes (by abetkin):
* version: 4.0 => dev
* type: Uncategorized => New feature
* stage: Unreviewed => Accepted
--
Ticket URL: <https://code.djangoproject.com/ticket/33780#comment:1>
Django
-------------------------------+------------------------------------
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
-------------------------------+------------------------------------
Old description:
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>