为何GitHub API使用PUT请求为存储库加注星标？

如何解决为何GitHub API使用PUT请求为存储库加注星标？

我正在开发自己的REST API，并且正在寻找其他完善的API，以查看它们在需要公开某种可对资源执行的操作时的功能。出现的一个功能是可以在GitHub上对存储库/要点进行星标和取消星标。根据{{​​3}}的说法，您可以与PUT /gists/{gist_id}/star一起注视，而与DELETE /gists/{gist_id}/star一起取消注视。

这是文档对their docs的评价：

PUT     Used for replacing resources or collections. For PUT requests with no body attribute,be sure to set the Content-Length header to zero.
DELETE  Used for deleting resources.

删除对我来说很有意义，但是为什么要使用PUT？由于您可以GET /gists/{gist_id}/star，看来“星形”是某种功能性资源。所以我想我只是想知道为什么用PUT而不是POST？

解决方法

所以我想我只是想知道为什么要使用PUT而不是POST？

在HTTP中，PUT在语义上的约束比POST严格一些-例如，PUT的语义是幂等的，这是在不可靠的网络上发送请求时很容易知道的事情； PUT告诉您，如果服务器接收到多个请求消息副本，就不会有问题。

（这很像是在问为什么要用GET而不是POST，只是区别要小一些）

这就是为什么当您有一个简单的远程创作用例（例如将文档上传到文档存储中）时，PUT是更好的选择-因为它允许通用客户端（例如浏览器）执行有用的事情而无需其他操作带外信息。

---

https://docs.github.com/en/rest/overview/resources-in-the-rest-api#http-verbs未定义HTTP方法的语义。 GET，PUT，POST等的标准化定义在RFC 7231中。

如果您查看RFC，您会发现HTTP PUT的语义也涵盖了“创建”：

PUT方法请求创建目标资源的状态或将其替换为请求消息有效负载中包含的表示形式定义的状态。

“使您的文档副本看起来像我的副本”是将信息传达给服务器的一种完全合理的方法，并且该消息的含义实际上并不完全取决于服务器是否已经知道该信息。处理请求时的文档。

---

我正在开发自己的REST API

请确保您查看Jim Webber's 2011 talk，我认为这对阐明基于Web的API如何“起作用”很有帮助。

,

我看到的一个原因是恒星“存在”，而这些路线只是在恒星上切换某种“活动”属性。因此，您不会使用POST，因为您不是在创建星星，而只是切换其活动属性。

编辑：这也只是基于我将如何实现这种方式的猜测，因为他们的文档有点稀疏。