Re: [討論] API沒資料，回200還是404比較好

看板Soft_Job作者時間1年前 (2022/06/22 15:17), 1年前編輯推噓13(13推 0噓 32→)
留言45則, 13人參與, 1年前最新討論串2/7 (看更多)
雖然我不是微軟派的，但是不得不說他們文件寫得真是認真 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://www.ptt.cc/bbs/Soft_Job/M.1655882271.A.1E5.html ※ 編輯: yfr (125.229.68.76 臺灣), 06/22/2022 15:18:22
→
06/22 15:28, 1年前 , 1F
你貼的這篇就建議404啊
06/22 15:28, 1F
推
06/22 16:01, 1年前 , 2F
找不到資源!=沒資料
06/22 16:01, 2F
推
06/22 16:17, 1年前 , 3F
這篇是說要回傳204
06/22 16:17, 3F
推
06/22 16:25, 1年前 , 4F
用ID Get的時候找不到資源的情況是404吧
06/22 16:25, 4F
→
06/22 16:30, 1年前 , 5F
大家熱烈討論還蠻棒的，資源不存在跟沒有結果是細微的不同
06/22 16:30, 5F
推
06/22 16:36, 1年前 , 6F
原來正解是204 ...
06/22 16:36, 6F
→
06/22 17:01, 1年前 , 7F
照這篇就是要404阿...
06/22 17:01, 7F
→
06/22 17:02, 1年前 , 8F
資源不存在不就是找不到資料（e.g.資料庫沒這筆資料）
06/22 17:02, 8F
→
06/22 17:03, 1年前 , 9F
204是指說找到這筆資料，但是內容是空的
06/22 17:03, 9F
推
06/22 17:03, 1年前 , 10F
這篇並不是說要回傳204
06/22 17:03, 10F
→
06/22 17:03, 1年前 , 11F
「未包含任何 respose 主體」並不是「未包含任何資料」
06/22 17:03, 11F
→
06/22 17:04, 1年前 , 12F
for example, a search operation yielding no matches
06/22 17:04, 12F
→
06/22 17:04, 1年前 , 13F
might be implemented with this behavior.
06/22 17:04, 13F
→
06/22 17:05, 1年前 , 14F
喔沒事 我切到英文版了 當我沒說（
06/22 17:05, 14F
→
06/22 17:05, 1年前 , 15F
這篇建議用204
06/22 17:05, 15F
→
06/22 17:05, 1年前 , 16F
不過我覺得是如果想要回傳是 {} 空陣列, 那就是 200
06/22 17:05, 16F
→
06/22 17:06, 1年前 , 17F
如果要直接表示沒有要回傳的東西, 就用 204
06/22 17:06, 17F
→
06/22 17:07, 1年前 , 18F
我個人不建議204的原因是，要是客戶端一律把回傳值先拿
06/22 17:07, 18F
→
06/22 17:07, 1年前 , 19F
去parse成json，那204或200不帶訊息都會出錯
06/22 17:07, 19F
推
06/22 17:11, 1年前 , 20F
客戶一律parse json那是客戶不看使用說明的問題？
06/22 17:11, 20F
推
06/22 17:12, 1年前 , 21F
GetById和search應該是不同的操作
06/22 17:12, 21F
→
06/22 17:15, 1年前 , 22F
search operation和resource是兩回事
06/22 17:15, 22F
推
06/22 17:17, 1年前 , 23F
你可以說是客戶的問題 你也可以減少客戶的犯錯空間
06/22 17:17, 23F
→
06/22 17:17, 1年前 , 24F
什麼叫做resource，什麼叫operation上面的段落有寫
06/22 17:17, 24F
→
06/22 17:21, 1年前 , 25F
有些實作沒辦法對應成資源的，可以把這種「非資源」的作業
06/22 17:21, 25F
→
06/22 17:21, 1年前 , 26F
公開成虛擬資源，如/add?operand1=99&operand2=1
06/22 17:21, 26F
→
06/22 17:22, 1年前 , 27F
簡單說， /名詞/{id} 這種找不到應該用404
06/22 17:22, 27F
→
06/22 17:22, 1年前 , 28F
動詞?參數={value1}&參數={value2} 這種才是找不到時可以用
06/22 17:22, 28F
→
06/22 17:23, 1年前 , 29F
204的
06/22 17:23, 29F
推
06/22 17:25, 1年前 , 30F
承樓上說的，要根據 RESTful 的設計應該盡量避免 URL 帶有
06/22 17:25, 30F
→
06/22 17:25, 1年前 , 31F
動詞的操作。可以在頁面的 route 上出現 login，但呼叫後端
06/22 17:25, 31F
→
06/22 17:25, 1年前 , 32F
時，登入的操作是要獲取 resource（以這種情景通常資源會命
06/22 17:25, 32F
→
06/22 17:25, 1年前 , 33F
名為 session
06/22 17:25, 33F
→
06/22 17:27, 1年前 , 34F
更正一下，應該說作業結果是沒結果時用204，找不到還是404
06/22 17:27, 34F
推
06/22 17:27, 1年前 , 35F
這麼明確的東西我不覺得是減少客戶犯錯空間。
06/22 17:27, 35F
推
06/22 18:17, 1年前 , 36F
404 無法表達是網址錯 還是沒資源
06/22 18:17, 36F
謝謝你們，我補充了一下context ※ 編輯: yfr (42.72.84.243 臺灣), 06/22/2022 18:59:09
→
06/22 20:39, 1年前 , 37F
用path parameter 的方式就回404，不是的話就用body回
06/22 20:39, 37F
→
06/22 20:39, 1年前 , 38F
空array 然後200
06/22 20:39, 38F
推
06/23 08:30, 1年前 , 39F
不懂的人去看國際標準： RFC2616。4xx開頭是 error 。2xx
06/23 08:30, 39F
→
06/23 08:30, 1年前 , 40F
開頭是 Info。
06/23 08:30, 40F
→
06/23 08:33, 1年前 , 41F
要看也是看 2014 後更新調整的 RFC7231，這個版本才把 REST
06/23 08:33, 41F
→
06/23 08:34, 1年前 , 42F
風格考慮進去，敘述中多了對表現層（representation）的解
06/23 08:34, 42F
→
06/23 08:34, 1年前 , 43F
釋
06/23 08:34, 43F
推
06/23 09:24, 1年前 , 44F
其實就在這個月出了RFC9110 XD
06/23 09:24, 44F
→
06/23 09:25, 1年前 , 45F
RFC9110 針對 Status Code 的敘述跟 RFC7231 沒有太多差異
06/23 09:25, 45F
‣ 更多 yfr 的文章
文章代碼(AID): #1Yii8V7b (Soft_Job)
討論串 (同標題文章)
完整討論串 (本文為第 2 之 7 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共7篇)
‣ 更多 yfr 的文章
文章代碼(AID): #1Yii8V7b (Soft_Job)