注意：一份报告要么存在，要么不存在，并且永远不会超过一个
GET /account/{id}/report
404（如果报告不存在）200（如果确实存在报告）但是如何初始化？ POST或PUT在端点上插入一个空的主体似乎是错误的（POST因为我们知道资源在哪里； PUT因为我们什么都不想要），但也许就是我。另一种选择可能是GET /account/{id}/report/init。
GET /account/{id}/report
200（如果存在报告）；退货报告200（如果报告不存在）；初始化并返回报告但是如何检查报告是否存在？
我的两种方法都不尽相同。在遵循REST原则的同时满足需求的合适方法是什么？
答案 0 :(得分：1)
在遵循REST原则的同时满足需求的合适方法是什么？
REST不在乎您为资源标识符使用什么拼写。
您应该记住两件事。首先，REST architectural style的参考应用程序是万维网，仅使用GET和POST就可以了。其次，caching是该故事的重要组成部分。
在HTTP中，当服务器响应不安全的请求而返回非错误状态代码时，这是对客户端（以及任何中间组件）的隐式指令，即先前缓存的表示应无效。
因此，我们通常希望安排编辑是对最重要资源的不安全请求，如果更改成功，则需要刷新这些重要资源。
那么，如果我想获取报告及其元数据？
GET /A3E7205B-6DC6-4685-9133-2759F739BC22
如果我想要元数据而不包含报告本身？
HEAD /A3E7205B-6DC6-4685-9133-2759F739BC22
如果我想更改报告
POST /A3E7205B-6DC6-4685-9133-2759F739BC22
PUT和PATCH是POST的有效替代方法，具有更具体的语义，因此在此使用是很好的。
从REST的角度来看， create 只是另一种 edit ：
资源可以映射到空集，这允许在该概念的任何实现存在之前就对该概念进行引用-Fielding
但是POST的一般灵活性的一部分是它支持创建具有不同标识符的资源。因此，您可以根据需要这样做。
如果报告不存在；初始化并返回报告
GET语义被认为是安全的-允许缓存通过预加载资源来改善体验，允许蜘蛛爬行它们，依此类推。这并不意味着您无法创建某些内容-HTTP限制了您的语义，而不是您的实现-只是您需要了解其含义。
HTTP不会尝试要求GET的结果是安全的。什么 确实要求操作的语义是安全的，并且 因此，这是实现的错误，而不是接口的错误 或该界面的用户，如果有任何结果导致 导致财产损失-Fielding 2002
您观察到：
发布...端点的空主体似乎是错误的
不，真的很好。您需要考虑其他一些用例（将空的正文发布到确实存在的报告意味着什么？）
但是，在有效地免费创建新报告的情况下，客户不需要了解详细信息吗？然后，只需告诉客户GET表示，然后根据需要创建您需要的内容即可。