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

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