我想针对以下场景使用适当的方法设计我的休息端点。 有一种幻灯片应该根据其他一些逻辑在主页上显示一段时间。这就是为什么我需要记录连接用户的最后一次查看日期时间。
因此，一旦用户查看这些幻灯片，通常会调用 API 来记录上次查看的日期。
A Request Event Listener 会监听我的请求然后更新连接的
User::$receptionDate我是否应该将 PATCH 方法作为我的终点：
PATCH with empty body {} : /users/me
或
HEADHEAD : /users/me
标准是：
在你的情况下 PATCH 似乎是更好的选择
HEAD 方法用于响应检索，就像没有正文的 GET，不用于更新
我应该为我的终点使用 PATCH 方法吗...
几乎可以肯定不是。当前已注册的 PATCH 参考文献 是RFC 5789：
PATCH，用于对资源应用部分修改.... PUT 方法已经定义为用完整的新主体覆盖资源，并且不能重复用于进行部分更改。否则，代理和缓存，甚至客户端和服务器，可能会对操作的结果感到困惑。
换句话说，PATCH 是我们用来告诉服务器修改其（内部）资源表示以匹配我们的副本的机制——这些是远程创作语义。
PATCH 消息中的空主体只有在您使用补丁文档格式时才有意义，而空补丁文档是有意义的。
如果您要向服务器发送receptionDate
属性的新值，并且不想 PUT 整个表示，则PATCH 可能有意义。例如，您可以使用 application/json-patch+json 文档
[
{ "op": "replace", "path": "/receptionDate", "value": "2023-04-10T12:34:56.789" }
]
但是如果您打算让服务器计算自己的 receptionDate 值，那么 PATCH 的语义是错误的。
HEAD 方法
不是一个好的选择：HEAD 具有 RFC 9110 描述的语义；允许通用组件假设 HEAD 请求是safe，也就是说没有可怕的副作用。
您可能会遇到的其他问题： HEAD 默认情况下是可缓存的——如果在某个中间点有可重用的响应，则 HEAD 请求不一定会一直传输到原始服务器。
一般规则 - 如果您打算（显式或隐式）向服务器发送信息，那么您应该使用 POST 除非更具体的不安全方法之一更适合.
复习一下 Fielding 2002 年关于 GET 的评论可能会有用
HTTP 不会尝试要求 GET 的结果是安全的。什么 它确实要求操作的语义是安全的，并且 因此这是实现的错误，而不是接口的错误 或该界面的用户，如果因此发生任何事情 造成财产损失
这通常成立——每个 HTTP 方法都有自己的语义；如果服务器没有实现其处理程序来尊重这些语义，那很好，前提是服务器对由此产生的任何错误承担责任。
所以你可以实现做不安全事情的 GET/HEAD 请求处理程序，和不意味着补丁的 PATCH 处理程序，等等。服务器始终有权根据需要维护其资源。
但是允许通用组件假定您的服务器理解消息的方式与 Web 上的所有其他服务器理解消息的方式相同（这是统一接口约束的一部分）；由于您的服务器试图成为一个非常特殊的雪花而发生的任何混乱都是您自己清理的责任。