Delicious 是否使用 GET 请求而不是 POST 进行创建,为什么我不应该这样做?
我正在查看Delicious API,看到以下是创建新书签的操作:
https://api.del.icio.us/v1/posts/add?&url={URL}&description={description}
看起来他们正在使用 GET 请求来创建服务器端数据库条目,我在其他地方读到的这些条目不应该使用 GET 请求来完成,而只能使用 POST 请求来完成。
我现在正在编写自己的 API,我认为让用户直接从 URL 与 API 交互真是太棒了。但除非您允许通过 GET 进行 CRUD 操作,否则您无法执行此操作。
那么,Delicious 真的是通过 GET 进行 CRUD 操作吗?我不应该在 API 中做同样的事情是否有一个重要原因,或者 POST 只是 CRUD 的强制要求,以防止意外调用?
I'm looking at the Delicious API and see the following is the operation to create a new bookmark:
https://api.del.icio.us/v1/posts/add?&url={URL}&description={description}
It looks like they're using a GET request to create server-side database entries, which I've read elsewhere shouldn't be done with GET requests, only with POST requests.
I'm writing my own API right now and I think that it's fabulous to let users interact with the API directly from the URL. But you can't do this unless you allow CRUD operations over GET.
So, is Delicious really doing CRUD operations over GET? Is there an important reason I shouldn't do the same thing in my API, or is POST just mandated for CRUD to prevent accidental invocation?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
意外调用是其中的一部分;这就是 HTTP 规范在谈论“幂等”方法时的含义。但你可能会争辩说,Delicious 所做的实际上是幂等的,只要 URL 只添加一次,无论你 GET 多少次。但更重要的是 GET 是 安全:
从界面设计的角度来看,您希望用户代理使 POST、PUT 和 DELETE 比 GET 更困难,或者至少明显不同不同,这样用户就可以依靠这种差异来提示他们的操作何时可能导致资源状态发生变化,因为他们对这些变化负责。使用 GET 进行更改,即使是幂等的,也会模糊责任线,尤其是在预取器 得到广泛部署。
Accidental invocation is part of it; that's what the HTTP spec means when it talks about "idempotent" methods. But you could argue that what Delicious is doing is actually idempotent as long as the URL only gets added once no matter how many times you GET. But more importantly is that GET is safe:
From an interface design standpoint, you want user-agents to make POST and PUT and DELETE more difficult than GET, or at least distinctly different, so that users can rely on that difference to hint when their actions might cause a change in the resource state, because they are responsible for those changes. Using GET to make changes, even if idempotent, blurs that line of accountability, especially when prefetchers are widely deployed.
这取决于你是否遵循 REST 原则 GET 改变事物是被禁止的。因此大多数人说 REST 使用 POST 进行更改。
但是 GET 和 POST 之间是有区别的。根据 RFC GET 请求始终有后续响应。如果您使用 POST,则需要遵循 Redirect-After-Post 模式。
另一个限制是 URL 的大小可能有限。因此,只有当您的输入数据足够短时,GET 才会起作用。所以delicious API有一个bug。您将无法通过 GET 参数添加所有可能的 url。
That depends if you follow the REST principles GET for changing things is forbidden. Therefore most people say with REST use POST for changes.
However there is a difference between GET and POST. According to the RFC GET requests have always a followup RESPONSE. And if you use POST you need to follow the Redirect-After-Post pattern.
Another limitation is that URLs may have a limited size. So GET will only work as long as your input data is short enough. So the delicious API has there a bug. You will not be able to add every possible url via a GET parameter.