REST:根据 RFC 2616 HTTP/1.1 规范正确的响应状态？

Question

我在 RFC-2616 浏览了 HTTP/1.1 协议(protocol)规范。我试图了解调用特定 REST 方法时应返回哪个状态代码。就我研究的协议(protocol)(链接)而言，我尝试将 REST 方法解析为正确的状态代码:

• 得到
  • 返回200 (ok)如果至少找到一个资源。
  • 如果没有找到(即返回空列表)，我是否应该返回 204(未找到)？
• 放置
  • 返回200 (ok) or 204 (not found)基于资源是否被修改
  • 此外返回501 (unimplemented)如果请求格式不正确或未被理解。
• 邮寄
  • 与 PUT 方法相同，不同之处在于 201 (created)如果新资源已添加到源，则返回
  • 基于常见的recommendation , POST 用于创建新资源，PUT 用于修改现有资源。如果我决定遵循此建议，那么在尝试修改现有资源 ex 时我应该返回什么。 POST api/v1/person/1?
• 补丁
  • 与 PUT 方法相同，不同之处在于它不像 PUT 那样替换整个资源，而是部分修改资源
  • W3 协议(protocol)中没有关于 PATCH REST 方法的字样 RFC-2616 , 它应该像 PUT 一样对待吗？
• 删除
  • 返回200 (ok)如果资源被删除并且 [204 (not found)] 如果不存在要删除的资源(id not found)。在 REST 实现的情况下，它是否复制 GET 响应原则？

我的“表”是否正确(尤其是带引号的语句 ？？只有 GET 应该在正文中返回请求本身，其余方法只是一个 URI 链接到一个标题中包含修改后的资源(新增、修改..)？

我的理解是否正确，是否存在另一个官方推荐(或者我们“有义务”)遵循的描述 REST 方法的来源？我对各种来源感到很困惑，这些来源给我对每种方法的不同答案以及这个非常冗长的 RFC-2616协议(protocol)。

最好的办法是有一个表格，简要而清楚地描述所有这 5 种方法，包括返回状态、正文内容和标题的可能性。

Answer 1

来自 RFC 7230

This HTTP/1.1 specification obsoletes RFC 2616

因此，任何为状态代码制定模式的尝试都应该从那里开始

Is my "table" correct

不是真的；查看 Stop Making it Hard 中 Kropat 的(非官方)流程图.