為此,Michael Kropat專門撰文分析了各個狀態碼的適用場景,以及我們為何要如此細緻地區分不同狀態碼,同時還談及了這麼做的好處。
有什麼是比返回一個HTTP狀態碼還要簡單的事情呢?頁面渲染了麼?如果渲染,那就返回200唄。頁面不存在?那就是404。需要將用戶重定向到另外一個頁面?那就使用302,也許301也行。
一切都是如此簡單,不過當有人跟你說,你並沒有以REST的方式做事情,你可能就要警醒了。新資源是否返回了RFC兼容、Roy-Fielding建議的狀態碼?只會是200麼?也許是204 No Content、202 Accepted,抑或是201 Created?
問題在於官方HTTP/1.1指南(RFC)最初是在1997年發布的。那時的我們還在使用Netscape Navigator、33.6kbps的調試解調器網上衝浪呢。這就好比是在現代商業戰略中使用孫子兵法一樣。這些寶貴的建議並不會隨著時間的流逝而發生變化。不過,我們需要真正理解他們。
如果有可視化的決策樹就好了,它可以幫助你快速識別與你的情況相吻合的狀態碼,這樣就能忽略掉那些不相關的了。請看下圖。
上圖看起來是顯而易見的,不過我發現很多人都會陷入其中,並且提出諸如「這種情況應該使用503 Service Unavailable還是404 Not Found呢」?停。如果你在完全不同的響應類別中思考具體的狀態碼,那就表明你的做法是完全錯誤的。再來看看上面這張圖。
在繼續之前我提出幾點:
最後再提一點:我其實並沒有什麼資格就這個主題發表自己的看法,我只不過閱讀過一些RFC並開發過一些APIs而已。如果覺得我說的不對,或是沒有使用你傾向於使用的狀態碼,那麼請在文末的評論中指出來,大家一起討論。
2XX/3XX雖說Facebook中很多聰明的開發者在構建APIs時只返回200,但我想說的是,狀態碼確實是非常重要的。現有的狀態碼對於現代網站/API來說有些太寬泛了。如果響應要以應用特定的格式來包含一些細節信息,比如說哪些欄位驗證失敗了,原因是什麼,這樣可以讓客戶端以更加有意義的方式來處理響應。既然如此,那為何不多花點時間來研究一下那些「不太常用」的HTTP狀態碼呢?
在談及為何說使用具體的狀態碼是非常重要的時候,人們很愛提到的一個原因就是HTTP是個分層系統,客戶端與伺服器之間可能存在著代理、緩存或是其他HTTP庫,如果響應碼有意義,那會讓這一切都工作地更好。不過,我覺得這個解釋站不住腳,比如說未來大家都使用上了HTTPS,我們也禁用掉了所有代理與緩存結點,你能說這時狀態碼就沒用了麼?
這裡,我想談談我認為狀態碼依然很重要的3點原因:
1. 客戶端可以針對不同的狀態碼採取不同的行為(或是可以輕鬆擴展以應對):
301 Moved Permanently與302 Found對於Google與其他搜尋引擎來說還有SEO的隱喻
301 Moved Permanently有緩存的含義,而429 Too Many Requests則沒有緩存的含義,諸如此類
客戶端庫可以通過一段時間的延遲後重試請求來處理429 Too Many Requests
客戶端庫可以採取類似的方式處理503 Service Unavilable
2. 很多狀態碼所表示的情況可以通過特殊的響應進行處理。
3. 不管信不信,目前很多流行的APIs建立了一些約定,比如說返回201 Created、429 Too Many Requests,或是503 Service Unavilable。如果遵循這些約定,那麼用戶在使用你的網站/API時就會更輕鬆,遇到問題時也更容易解決。