为什么 Django 和 CherryPy 本身不支持基于 HTTP 动词的调度?
POST 到 URL 与 GET、DELETE 或 PUT 不同。 这些行动有本质上的不同。 然而,Django 的调度机制似乎忽略了它们。 基本上,人们被迫要么完全忽略 HTTP 动词,要么在每个视图上执行此操作:
def my_view(request, arg1, arg2):
if request.method == 'GET':
return get_view(request, arg1, arg2)
if request.method == 'POST':
return post_view(request, arg1, arg2)
return http.HttpResponseNotAllowed(['GET', 'POST'])
我在网络上找到的几个解决方案(此片段用于基于动词的调度,或这个装饰器用于动词要求)不是很优雅,因为它们显然只是解决方法。
CherryPy 的情况似乎是一样的。 据我所知,唯一能做到这一点的框架是 web.py 和 Google App Engine。
我认为这是 Web 框架的一个严重的设计缺陷。 有人同意吗? 或者这是基于我忽略的原因/要求而故意做出的决定?
It's not the same to POST to an URL than to GET it, DELETE it or PUT it. These actions are fundamentally different. However, Django seems to ignore them in its dispatch mechanism. Basically, one is forced to either ignore HTTP verbs completely or do this on every view:
def my_view(request, arg1, arg2):
if request.method == 'GET':
return get_view(request, arg1, arg2)
if request.method == 'POST':
return post_view(request, arg1, arg2)
return http.HttpResponseNotAllowed(['GET', 'POST'])
The few solutions I have found for this in the web (this snippet for verb-based dispatch, or this decorator for verb requirement) are not very elegant as they are clearly just workarounds.
The situation with CherryPy seems to be the same. The only frameworks I know of that get this right are web.py and Google App Engine's.
I see this as a serious design flaw for a web framework. Does anyone agree? Or is it a deliberate decision based on reasons/requirements I ignore?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
我不能代表 Django,但在 CherryPy 中,您可以使用单个配置条目为每个 HTTP 动词提供一个函数:
但是,我见过一些情况,这是不可取的。
一个例子是硬重定向,无论动词如何。
另一种情况是大多数处理程序只处理 GET。 在这种情况下,有一千个页面处理程序都名为“GET”,这尤其令人烦恼。 在装饰器中表达这一点比在函数名称中表达更漂亮:
我看到的另一个常见的方法是查找与数据库中的资源相对应的数据,无论动词如何,这都应该发生:
CherryPy 尝试不为您做出决定,但会做出决定如果你想要的话,这很容易(一句台词)。
I can't speak for Django, but in CherryPy, you can have one function per HTTP verb with a single config entry:
However, I have seen some situations where that's not desirable.
One example would be a hard redirect regardless of verb.
Another case is when the majority of your handlers only handle GET. It's especially annoying in that case to have a thousand page handlers all named 'GET'. It's prettier to express that in a decorator than in a function name:
Another common one I see is looking up data corresponding to the resource in a database, which should happen regardless of verb:
CherryPy tries to not make the decision for you, yet makes it easy (a one-liner) if that's what you want.
从谷歌上看到这个,并想到更新。
Django
仅供参考,Django 现在支持基于类的视图。 您可以扩展通用类
View
并添加get()
、post()
、put()
等方法等等。例如 -dispatch()
部分处理这个 -然后你可以在 urls.py 中使用它 -
更多详细信息。
CherryPy
CherryPy 现在也支持这一点。 他们对此有一个完整页面。
Came across this from Google, and thought of updating.
Django
Just FYI, This is now supported in Django as class based views. You can extend the generic class
View
and add methods likeget()
,post()
,put()
etc. E.g. -The
dispatch()
part handles this-Then you can use it in
urls.py
-More details.
CherryPy
CherryPy now also supports this. They have a full page on this.
我相信 django 的决定是因为通常只需
GET
和POST
就足够了,这使框架更简单地满足其要求。 “不关心”使用哪个动词是非常方便的。然而,还有很多其他框架可以基于动词进行调度。 我喜欢 werkzeug,它可以轻松定义自己的调度代码,这样你就可以基于调度随心所欲,随心所欲。
I believe the decision for django was made because usually just
GET
andPOST
is enough, and that keeps the framework simpler for its requirements. It is very convenient to just "not care" about which verb was used.However, there are plenty other frameworks that can do dispatch based on verb. I like werkzeug, it makes easy to define your own dispatch code, so you can dispatch based on whatever you want, to whatever you want.
因为这个DIY并不难。 只要有一本字典,其中包含每个类别中可接受的动词功能即可。
Because this is not hard to DIY. Just have a dictionary of accepted verbs to functions in each class.