1

我正在查看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 防止意外调用？

4

2 回答 2

1

意外调用是其中的一部分；这就是 HTTP 规范在谈论“幂等”方法时的含义。但是你可以争辩说，只要 URL 只被添加一次，无论你 GET 多少次，Delicious 所做的实际上是幂等的。但更重要的是 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 进行更改，即使是幂等的，也会模糊责任界限，尤其是在广泛部署预取器时。

于 2012-01-10T15:26:03.357 回答
1

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

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

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

于 2012-01-10T11:51:52.560 回答