其實這都只是參考設計
怎樣處理都行
前端能接的起來就好
我個人則是傾向200或204
原因沒有什麼
在一些前端套件
非2xx是會進exception
正確的URL但是沒有資源
會變成理論上不該exception
但是4xx讓它進入exception
簡單來說在前端的顯示上
沒有資源與真正的404是有所區別的
如果同為404造成前端在處理上
要再區分404的差異
怎樣選擇都是一種trade off
我個人的選擇會是不造成前端麻煩的方式

前端淚推

比較麻煩的是有些路由器會劫持 4xx 狀態，然後返回一個自己的頁面…然後有些人可能誤解 404 不能返回頁面...https://i.imgur.com/4APL4jy.pngGitHub 這樣的風險就是有可能被路由器或是瀏覽器劫持，可是作法是合乎規範的，反而 CODE 傳 200 卻給 404 頁面是積習難改了...

推這篇

200+1不能只自己爽

有時候明明是標準，但也只能跟一堆不標準亂搞的client妥協web上充滿這種事情啦不過追根究底來說這也可能是API設計或呼叫API的人想法還不

推

夠適應RESTful，這種資源路徑不是查詢，極端一點來說client應該本來就知道資源存在才去存取(由別的API取得id、POST或PUT成功後、HATEOAS...)，而不是去試不知道有沒有的資源

是，如同 ssccg 大說的，以 REST 風格設計時，理應不會有「正確的 URL 卻沒有資源」這件事，因為 URL 就對應資源使用者想要訪問不存在的路徑，就是想要拿不存在的資源，此時的 404 既合乎 HTTP Code 的規範也合乎 REST 風格在開發資源和時程充足的狀況下，發生這種事是要回頭檢視為什麼會訪問不存在的路徑或者說資源

我覺得原po只是想問查無資料的情境吧？

身為前端，在UX沒有明確設計對於"沒有資源"或"路徑不存在"要呈現的差異，我傾向以發生問題的時候可以迅速讓技術團隊知道是什麼原因的設計方式，所以終究還是看團隊約定

Api未必只有前端會call...Microservice 的情況api大多是其他後端app在call後端call的時候4xx拋出例外是合理的。包含url正確但是沒有資源（GetById時）

混合多種資源的 API 通常不會採 RESTful 設計

推這篇

有些企業內部的設備會攔截 200 以外的 response