美味的用途是否获得创建请求而不是帖子，为什么我不应该这样做？

Question

我在看 美味的API 并查看以下是创建新书签的操作：

https://api.del.icio.us/v1/posts/add?&url={URL}&description={description}

看来他们正在使用一个GET请求来创建服务器端数据库条目，我在其他地方不应该使用get请求来完成此内容，而仅在POST请求中使用。

我现在正在编写自己的API，我认为直接从URL与API交互是很棒的。但是，除非您允许Crud操作进行，否则您将无法做到这一点。

那么，美味的真的是在进行CRUD操作吗？我是否应该在API中做同样的事情，或者刚刚要求CRUD防止意外调用的重要原因？

Answer 1

意外调用是其中的一部分；这就是HTTP规格在谈论“ iDempotent”方法时的含义。但是，您可以说，只要只有一旦添加了多少次，就可以做什么，只要URL才能添加多少次。但更重要的是，那是 安全的:

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

从接口设计的角度来看，您 想 用户代理使帖子和放置和删除和删除比获得或至少完全不同的难度，因此用户可以依靠该差异来提示，因为他们的操作可能会导致资源状态发生变化，因为他们 是 负责这些变化。使用Get进行更改，即使愿意的话也模糊了那条问责制，尤其是在 预摘要 被广泛部署。

Answer 2

这取决于您是否遵循其余的原则来改变事物。因此，大多数人都说休息帖子进行更改。

但是，获得和邮寄之间存在区别。根据RFC，GET请求始终具有后续响应。而且，如果您使用帖子，则需要遵循重定向序列图案。

另一个限制是URL的大小可能有限。因此，只要您的输入数据足够短，获得就可以工作。因此，美味的API有一个错误。您将无法通过GET参数添加所有可能的URL。