如果我请求从数据库获取一些数据而不发送任何更新，但是我正在标记数据库中的记录说数据已被获取，这是否使其成为PATCH请求或GET？ / p>
答案 0 :(得分：1)
简短的回答：不，它仍然是GET。
RFC 7231定义了safe
如果请求方法的定义语义本质上是只读的，则将其视为“安全”。
此安全方法的定义不会阻止实施 包括可能有害的行为，不是 完全只读，或者在调用安全性时引起副作用 方法。然而，重要的是客户没有 要求采取其他行为，并且不承担任何责任 它。例如，大多数服务器会附加请求信息以进行访问 每个响应完成后的日志文件，无论 方法，即使日志存储可能会被认为是安全的 变满并使服务器崩溃。同样，启动了安全请求 通过在网络上选择广告通常会偏偏 广告帐户收费的效果。
因此，如果客户端尝试检索资源的当前表示形式， 您的实现恰好在一边做一些记账的事实并不会改变请求的语义。
HTTP前端的部分功能是使客户端与服务器的基础实现细节完全隔离-一切从外部看起来都像是一个愚蠢的网站。
答案 1 :(得分：1)
如果您通读safe的定义，则HTTP spec相当清楚：
如果请求方法的定义语义本质上是只读的，则它们被认为是“安全的”。也就是说，由于对目标资源应用安全方法，客户端不会请求也不会期望原始服务器上的任何状态更改。同样，合理使用安全方法不会对原始服务器造成任何伤害，财产损失或异常负担。此安全方法的定义不会阻止实现包含潜在有害行为，该行为不是完全只读的，或在调用安全方法时引起副作用的行为。但是重要的是，客户端没有请求其他行为，因此不能追究其责任。例如，大多数服务器在每次响应完成后都将请求信息附加到访问日志文件中，而不考虑方法，即使日志存储空间可能已满并使服务器崩溃，这也被认为是安全的。同样，通过选择网络上的广告发起的安全请求通常会产生向广告帐户收费的副作用。
...
因此，只要客户端不知道状态更改，通过GET触发的下载进行状态更改就可以了。
在某些情况下，通过GET公开状态更改可能会带来风险。试想一下，一个爬网程序会调用几个订购比萨饼之类的URI。根据规范，这很好，并且搜寻器不得对此命令负责。这只是在告诉你这是你的错。
话虽如此，如果您对某些HTTP操作感到不舒服，可以随时使用POST，因为POST确实允许您根据资源自身的语义来处理请求。
这将引导我重新思考您的设计的下一点。在我看来，返回包含其自身状态的某些文档有些奇怪。通常，此类信息是有关文档的元数据，而不是资源本身。在这里，您可以使用HTTP标头将此类信息传达给客户端，也可以设计该资源的状态，作为进一步的资源，您可以提示客户端有关是否有兴趣为其提供链接以进行查找。
无论如何，尽管禁止通过GET检索资源来执行状态更改，但也不禁止。我想花更多的心思来考虑是要在资源本身中包含状态还是通过自己的资源公开状态。
答案 2 :(得分：0)
这应该是GET。
您正在使用此请求修改某些数据，但是您没有修改获取的资源，修改后的数据是某种元数据。
仅当在数据库中标记记录会导致在下一个请求中返回具有不同数据的资源时，才应该是PATCH请求。