Delicious获取创建请求而不是POST请求，为什么我不应该做同样的事情？

Question

我正在查看Delicious API，并看到以下是创建新书签的操作：

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

看起来他们正在使用GET请求来创建服务器端数据库条目，我在其他地方读到的内容不应该用GET请求来完成，只能用POST请求来完成。

我现在正在编写自己的API，我认为让用户直接从URL与API交互是非常棒的。但是您不能这样做，除非您允许CRUD操作超过GET。

那么，美味真的是做CRUD操作而不是GET吗？有没有什么重要的原因让我不应该在我的API中做同样的事情，或者POST只是强制用于CRUD以防止意外调用？

Answer 1

意外调用是其中的一部分；当HTTP规范谈到“幂等”方法时，这就是它的意思。但你可能会说doing所做的事情实际上是幂等的，只要URL只被添加一次，无论你得到多少次。但更重要的是，GET是safe

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进行更改，即使是幂等的，也模糊了责任的界限，特别是当prefetchers被广泛部署时。

Answer 2

这取决于你是否遵循REST原则，因为改变事情是被禁止的。因此，大多数人说with REST使用POST进行更改。

然而，GET和POST是有区别的。根据RFC，GET请求总是有一个后续响应。如果您使用POST，则需要遵循Post-After-Redirect模式。

另一个限制是URL可能具有有限的大小。因此，只有在输入数据足够短的情况下，GET才有效。所以这个美味的API有一个bug。您将无法通过GET参数添加所有可能的url。