作者yfr ()
看板Soft_Job
标题Re: [讨论] API没资料，回200还是404比较好
时间Wed Jun 22 15:17:49 2022
虽然我不是微软派的，但是不得不说他们文件写得真是认真
https://docs.microsoft.com/zh-tw/azure/architecture/best-practices/api-design
好入手，广度，深度也都有一定程度的水准
---
(感谢ssccg提醒，我更正一下内容跟context
我觉得原文并没有把case列清楚
仔细想想我觉得大家可能都讲对，只是想的东西没对齐，我就献丑列了一下
搞不好有人可以补充？
* GET {schema}://{host}:{port}/api/v1.0/members
1. members 资料为空
2. 预设的 page, size 搜寻结果为空阵列
3. 没有这个 endpoint
* GET {schema}://{host}:{port}/api/v1.0/members/{uuid}
4. 没有找到对应 uuid 的 member
* GET {schema}://{host}:{port}/api/v1.0/members/{uuid}/properties
5. properties 资料为空
6. 预设的 page, size 搜寻结果为空阵列
7. 没有这个 endpoint
※ 引述《Geison (Angels)》之铭言：
: 我看有些是状态码200，空data
: 但有些又是做404，然後回个message 数据不存在之类的
: 这哪一种做法比较好？
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 125.229.68.76 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1655882271.A.1E5.html
※ 编辑: yfr (125.229.68.76 台湾), 06/22/2022 15:18:22
1F：→ ssccg: 你贴的这篇就建议404啊 06/22 15:28
2F：推 x51811danny: 找不到资源!=没资料 06/22 16:01
3F：推 xup6y3ru04: 这篇是说要回传204 06/22 16:17
4F：推 s06yji3: 用ID Get的时候找不到资源的情况是404吧 06/22 16:25
5F：→ yfr: 大家热烈讨论还蛮棒的，资源不存在跟没有结果是细微的不同 06/22 16:30
6F：推 smalldra: 原来正解是204 ... 06/22 16:36
7F：→ crazycy: 照这篇就是要404阿... 06/22 17:01
8F：→ crazycy: 资源不存在不就是找不到资料（e.g.资料库没这笔资料） 06/22 17:02
9F：→ crazycy: 204是指说找到这笔资料，但是内容是空的 06/22 17:03
10F：推 Romulus: 这篇并不是说要回传204 06/22 17:03
11F：→ Romulus: 「未包含任何 respose 主体」并不是「未包含任何资料」 06/22 17:03
12F：→ iterator: for example, a search operation yielding no matches 06/22 17:04
13F：→ iterator: might be implemented with this behavior. 06/22 17:04
14F：→ Romulus: 喔没事 我切到英文版了 当我没说（ 06/22 17:05
15F：→ Romulus: 这篇建议用204 06/22 17:05
16F：→ iterator: 不过我觉得是如果想要回传是 {} 空阵列, 那就是 200 06/22 17:05
17F：→ iterator: 如果要直接表示没有要回传的东西, 就用 204 06/22 17:06
18F：→ Romulus: 我个人不建议204的原因是，要是客户端一律把回传值先拿 06/22 17:07
19F：→ Romulus: 去parse成json，那204或200不带讯息都会出错 06/22 17:07
20F：推 s06yji3: 客户一律parse json那是客户不看使用说明的问题？ 06/22 17:11
21F：推 s06yji3: GetById和search应该是不同的操作 06/22 17:12
22F：→ ssccg: search operation和resource是两回事 06/22 17:15
23F：推 Romulus: 你可以说是客户的问题 你也可以减少客户的犯错空间 06/22 17:17
24F：→ ssccg: 什麽叫做resource，什麽叫operation上面的段落有写 06/22 17:17
25F：→ ssccg: 有些实作没办法对应成资源的，可以把这种「非资源」的作业 06/22 17:21
26F：→ ssccg: 公开成虚拟资源，如/add?operand1=99&operand2=1 06/22 17:21
27F：→ ssccg: 简单说， /名词/{id} 这种找不到应该用404 06/22 17:22
28F：→ ssccg: 动词?参数={value1}&参数={value2} 这种才是找不到时可以用 06/22 17:22
29F：→ ssccg: 204的 06/22 17:23
30F：推 Hsins: 承楼上说的，要根据 RESTful 的设计应该尽量避免 URL 带有 06/22 17:25
31F：→ Hsins: 动词的操作。可以在页面的 route 上出现 login，但呼叫後端 06/22 17:25
32F：→ Hsins: 时，登入的操作是要获取 resource（以这种情景通常资源会命 06/22 17:25
33F：→ Hsins: 名为 session 06/22 17:25
34F：→ ssccg: 更正一下，应该说作业结果是没结果时用204，找不到还是404 06/22 17:27
35F：推 s06yji3: 这麽明确的东西我不觉得是减少客户犯错空间。 06/22 17:27
36F：推 Jichang: 404 无法表达是网址错 还是没资源 06/22 18:17
谢谢你们，我补充了一下context
※ 编辑: yfr (42.72.84.243 台湾), 06/22/2022 18:59:09
37F：→ qoo456alex: 用path parameter 的方式就回404，不是的话就用body回 06/22 20:39
38F：→ qoo456alex: 空array 然後200 06/22 20:39
39F：推 DrTech: 不懂的人去看国际标准： RFC2616。4xx开头是 error 。2xx 06/23 08:30
40F：→ DrTech: 开头是 Info。 06/23 08:30
41F：→ Hsins: 要看也是看 2014 後更新调整的 RFC7231，这个版本才把 REST 06/23 08:33
42F：→ Hsins: 风格考虑进去，叙述中多了对表现层（representation）的解 06/23 08:34
43F：→ Hsins: 释 06/23 08:34
44F：推 Romulus: 其实就在这个月出了RFC9110 XD 06/23 09:24
45F：→ Hsins: RFC9110 针对 Status Code 的叙述跟 RFC7231 没有太多差异 06/23 09:25