REST：根据RFC2616HTTP/1.1规范，响应状态正确吗？

我浏览了HTTP/1.1协议规范，试图了解在调用特定REST方法时应该返回哪些状态代码。就我所研究的协议（链接）而言，我试图将REST方法解析为正确的状态代码：

• 得到
  • 在至少找到一个资源时返回
  • 如果未找到任何内容（即返回空列表），是否应返回204（未找到）
• 放
  • 根据是否修改资源返回
  • 此外，如果请求格式不正确或无法理解，则返回
• 职位
  • 如果已将新资源添加到orign，则返回具有差异的like PUT方法
  • 基于common，POST应用于创建新资源，PUT应用于修改现有资源。如果我决定遵循此建议，在尝试修改现有资源（例如api/v1/person/1之后的

    ）时，我应该返回什么

• 补丁
  • 与PUT方法相同，但不同的是，它不像PUT方法那样替换整个资源，而是部分修改资源
  • W3协议中并没有关于补丁REST方法的说法，它应该像PUT一样对待吗
• 删除
  • 如果资源已删除，则返回[204（未找到）]，如果没有要删除的资源（未找到id），则返回[204（未找到）]。在REST实现的情况下，它是否复制了GET响应原则

我的“table”正确吗（特别是带有引号的语句

？

？正确吗？只有GET应该在主体中返回请求本身，而其余的方法只是一个URI链接，指向头中包含的修改过的资源（新添加的、修改过的…）

我的理解正确吗？是否存在另一个正式描述REST方法的来源，这是推荐的（或者我们“有义务”）遵循的？我对各种来源感到相当困惑，这些来源给了我对每种方法以及这个非常冗长的协议的不同答案

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

From

此HTTP/1.1规范淘汰了RFC 2616

因此，任何试图找出状态代码模式的尝试都应该从那里开始

我的“桌子”对吗

---

不太可能；请看中Kropat（非官方）的流程图。

尝试将状态代码与方法对齐可能不是一个有用的想法。有方法定义的链接。可能值得注意的是：鉴于当前的HTTP/1.1规范已模块化为多个部分，RFC 7231“语义和内容”也淘汰了RFC 2616，是现在定义状态代码语义的特定部分链接已随时间发生变化：