作者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/m.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