其實這都只是參考設計
怎樣處理都行
前端能接的起來就好
我個人則是傾向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.htmlqwe703021樓前端淚推 06/23 13:28
→ Hsins2樓比較麻煩的是有些路由器會劫持 4xx 狀態,然後返回一個自己 06/23 13:47
→ Hsins3樓的頁面… 06/23 13:47
→ Hsins4樓然後有些人可能誤解 404 不能返回頁面... 06/23 13:50
→ Hsins5樓 06/23 13:50 → Hsins6樓GitHub 這樣的風險就是有可能被路由器或是瀏覽器劫持,可是 06/23 13:51
→ Hsins7樓作法是合乎規範的,反而 CODE 傳 200 卻給 404 頁面是積習 06/23 13:51
→ Hsins8樓難改了... 06/23 13:52
kewang9樓推這篇 06/23 14:01
neo527710樓200+1不能只自己爽 06/23 14:10
→ ssccg11樓有時候明明是標準,但也只能跟一堆不標準亂搞的client妥協 06/23 14:47
→ ssccg12樓web上充滿這種事情啦 06/23 14:47
→ ssccg13樓不過追根究底來說這也可能是API設計或呼叫API的人想法還不 06/23 14:52
Geison14樓推 06/23 14:53
→ ssccg15樓夠適應RESTful,這種資源路徑不是查詢,極端一點來說client 06/23 14:54
→ ssccg16樓應該本來就知道資源存在才去存取(由別的API取得id、POST或 06/23 14:55
→ ssccg17樓PUT成功後、HATEOAS...),而不是去試不知道有沒有的資源 06/23 14:55
Hsins18樓是,如同 ssccg 大說的,以 REST 風格設計時,理應不會有 06/23 14:56
→ Hsins19樓「正確的 URL 卻沒有資源」這件事,因為 URL 就對應資源 06/23 14:56
→ Hsins20樓使用者想要訪問不存在的路徑,就是想要拿不存在的資源,此 06/23 14:57
→ Hsins21樓時的 404 既合乎 HTTP Code 的規範也合乎 REST 風格 06/23 14:58
→ Hsins22樓在開發資源和時程充足的狀況下,發生這種事是要回頭檢視為 06/23 14:58
→ Hsins23樓什麼會訪問不存在的路徑或者說資源 06/23 14:59
→ lazarus112124樓我覺得原po只是想問查無資料的情境吧? 06/23 15:23
→ sharek25樓身為前端,在UX沒有明確設計對於"沒有資源"或"路徑不存在 06/23 18:07
→ sharek26樓"要呈現的差異,我傾向以發生問題的時候可以迅速讓技術團 06/23 18:07
→ sharek27樓隊知道是什麼原因的設計方式,所以終究還是看團隊約定 06/23 18:07
s06yji328樓Api未必只有前端會call... 06/23 19:13
s06yji329樓Microservice 的情況api大多是其他後端app在call 06/23 19:15
不管哪邊call都一樣要處理
同樣404後要再分析是錯誤還是空資源
s06yji330樓後端call的時候4xx拋出例外是合理的。 06/23 19:44