虽然我不是微软派的，但是不得不说他们文件写得真是认真
https://docs.microsoft.com/zh-tw/azure/architecture/best-practices/api-design
好入手，广度，深度也都有一定程度的水准

你贴的这篇就建议404啊

找不到资源!=没资料

这篇是说要回传204

用ID Get的时候找不到资源的情况是404吧

大家热烈讨论还蛮棒的，资源不存在跟没有结果是细微的不同

原来正解是204 ...

照这篇就是要404阿...资源不存在不就是找不到资料（e.g.数据库没这笔资料）204是指说找到这笔资料，但是内容是空的

这篇并不是说要回传204“未包含任何 respose 主体”并不是“未包含任何资料”

for example, a search operation yielding no matchesmight be implemented with this behavior.

喔没事 我切到英文版了 当我没说（这篇建议用204

不过我觉得是如果想要回传是 {} 空阵列, 那就是 200如果要直接表示没有要回传的东西, 就用 204

我个人不建议204的原因是，要是客户端一律把回传值先拿去parse成json，那204或200不带讯息都会出错

客户一律parse json那是客户不看使用说明的问题？GetById和search应该是不同的操作

search operation和resource是两回事

你可以说是客户的问题 你也可以减少客户的犯错空间

什么叫做resource，什么叫operation上面的段落有写有些实作没办法对应成资源的，可以把这种“非资源”的作业公开成虚拟资源，如/add?operand1=99&operand2=1简单说， /名词/{id} 这种找不到应该用404动词?参数={value1}&参数={value2} 这种才是找不到时可以用204的

承楼上说的，要根据 RESTful 的设计应该尽量避免 URL 带有动词的操作。可以在页面的 route 上出现 login，但呼叫后端时，登入的操作是要获取 resource（以这种情景通常资源会命名为 session

更正一下，应该说作业结果是没结果时用204，找不到还是404

这么明确的东西我不觉得是减少客户犯错空间。

404 无法表达是网址错 还是没资源

用path parameter 的方式就回404，不是的话就用body回空array 然后200

不懂的人去看国际标准： RFC2616。4xx开头是 error 。2xx开头是 Info。

要看也是看 2014 后更新调整的 RFC7231，这个版本才把 REST风格考虑进去，叙述中多了对表现层（representation）的解释

其实就在这个月出了RFC9110 XD

RFC9110 针对 Status Code 的叙述跟 RFC7231 没有太多差异