作者ripple0129 (perry tsai)
看板Soft_Job
標題Re: [討論] API沒資料，回200還是404比較好
時間Thu Jun 23 13:18:31 2022
其實這都只是參考設計
怎樣處理都行
前端能接的起來就好
我個人則是傾向200或204
原因沒有什麼
在一些前端套件
非2xx是會進exception
正確的URL但是沒有資源
會變成理論上不該exception
但是4xx讓它進入exception
簡單來說在前端的顯示上
沒有資源與真正的404是有所區別的
如果同為404造成前端在處理上
要再區分404的差異
怎樣選擇都是一種trade off
我個人的選擇會是不造成前端麻煩的方式
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 49.216.235.228 (臺灣)
※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1655961513.A.860.html
1F：推 qwe70302: 前端淚推06/23 13:28
2F：→ Hsins: 比較麻煩的是有些路由器會劫持 4xx 狀態，然後返回一個自己06/23 13:47
3F：→ Hsins: 的頁面…06/23 13:47
4F：→ Hsins: 然後有些人可能誤解 404 不能返回頁面...06/23 13:50
6F：→ Hsins: GitHub 這樣的風險就是有可能被路由器或是瀏覽器劫持，可是06/23 13:51
7F：→ Hsins: 作法是合乎規範的，反而 CODE 傳 200 卻給 404 頁面是積習06/23 13:51
8F：→ Hsins: 難改了...06/23 13:52
9F：推 kewang: 推這篇06/23 14:01
10F：推 neo5277: 200+1不能只自己爽06/23 14:10
11F：→ ssccg: 有時候明明是標準，但也只能跟一堆不標準亂搞的client妥協06/23 14:47
12F：→ ssccg: web上充滿這種事情啦06/23 14:47
13F：→ ssccg: 不過追根究底來說這也可能是API設計或呼叫API的人想法還不06/23 14:52
14F：推 Geison: 推06/23 14:53
15F：→ ssccg: 夠適應RESTful，這種資源路徑不是查詢，極端一點來說client06/23 14:54
16F：→ ssccg: 應該本來就知道資源存在才去存取(由別的API取得id、POST或06/23 14:55
17F：→ ssccg: PUT成功後、HATEOAS...)，而不是去試不知道有沒有的資源06/23 14:55
18F：推 Hsins: 是，如同 ssccg 大說的，以 REST 風格設計時，理應不會有06/23 14:56
19F：→ Hsins: 「正確的 URL 卻沒有資源」這件事，因為 URL 就對應資源06/23 14:56
20F：→ Hsins: 使用者想要訪問不存在的路徑，就是想要拿不存在的資源，此06/23 14:57
21F：→ Hsins: 時的 404 既合乎 HTTP Code 的規範也合乎 REST 風格06/23 14:58
22F：→ Hsins: 在開發資源和時程充足的狀況下，發生這種事是要回頭檢視為 06/23 14:58
23F：→ Hsins: 什麼會訪問不存在的路徑或者說資源06/23 14:59
24F：→ lazarus1121: 我覺得原po只是想問查無資料的情境吧？06/23 15:23
25F：→ sharek: 身為前端，在UX沒有明確設計對於"沒有資源"或"路徑不存在06/23 18:07
26F：→ sharek: "要呈現的差異，我傾向以發生問題的時候可以迅速讓技術團06/23 18:07
27F：→ sharek: 隊知道是什麼原因的設計方式，所以終究還是看團隊約定06/23 18:07
28F：推 s06yji3: Api未必只有前端會call...06/23 19:13
29F：推 s06yji3: Microservice 的情況api大多是其他後端app在call06/23 19:15
不管哪邊call都一樣要處理
同樣404後要再分析是錯誤還是空資源
※ 編輯: ripple0129 (49.216.235.228 臺灣), 06/23/2022 19:42:25
30F：推 s06yji3: 後端call的時候4xx拋出例外是合理的。 06/23 19:44
31F：推 s06yji3: 包含url正確但是沒有資源（GetById時） 06/23 19:46
這樣說好了
如果是前端用的api
然後api去取用了資源的api返回404
這樣要給前端api返回404還是200
如果這個api是混合多種資源產生的資料
又該怎麼返回資料
當使用404時狀況會複雜很多
直白點來說
404符合規範但串接時沒有200方便許多
我可以明確知道是URL有問題還是沒資料
※ 編輯: ripple0129 (49.216.235.228 臺灣), 06/23/2022 20:49:59
32F：推 s06yji3: 這沒有簡答。混合多種資源的api應該根據業務邏輯設計api 06/23 21:18
33F：→ s06yji3: gateway 來提供服務。上面推文的想法是就單一資源的api 06/23 21:18
34F：→ s06yji3: 來說的。 06/23 21:18
35F：推 s06yji3: 返回200你還是得依靠response body 來判斷。跟status cod 06/23 21:22
36F：→ s06yji3: e沒有直接的關係 06/23 21:22
37F：推 s06yji3: 另外，空資源是指search 沒有結果嗎？是的話，200是合理 06/23 21:31
38F：→ s06yji3: 的。這和GetById是不一樣的操作。 06/23 21:31
39F：推 Hsins: 混合多種資源的 API 通常不會採 RESTful 設計 06/23 21:46
40F：推 viper9709: 推這篇 06/23 23:53
41F：→ travelerX: 有些企業內部的設備會攔截 200 以外的 response 06/24 16:02