Delicious 是否使用 GET 请求而不是 POST 进行创建,为什么我不应该这样做?

发布于 2024-12-26 07:36:15 字数 489 浏览 1 评论 0原文

我正在查看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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

月光色 2025-01-02 07:36:15

意外调用是其中的一部分;这就是 HTTP 规范在谈论“幂等”方法时的含义。但你可能会争辩说,Delicious 所做的实际上是幂等的,只要 URL 只添加一次,无论你 GET 多少次。但更重要的是 GET 是 安全

The important distinction here is that the user
did not request the side-effects, so therefore
cannot be held accountable for them.

从界面设计的角度来看,您希望用户代理使 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:

The important distinction here is that the user
did not request the side-effects, so therefore
cannot be held accountable for them.

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.

泛滥成性 2025-01-02 07:36:15

这取决于你是否遵循 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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文