2012-06-08 43 views
1

我想知道如何在我的REST API中響應。瞭解REST響應和HTTP狀態代碼

有效實施例:

http://blah.com/api/v1/dosomething/123 

上面是一個有效的請求和目前我有200與JSON響應一個HTTP狀態

{ 
    "dosomething": { 
     "status": "OK", 
     "results": "123" 
    } 
} 

現在的問題是,如果傳遞的參數爲無效(我期待一串整數),我是否返回200的HTTP響應並將錯誤狀態返回到JSON響應中,或者我應該傳遞類似HTTP 400響應(錯誤的請求)並列出錯誤/ JSON響應中的請求問題?

錯誤示例:

http://blah.com/api/v1/dosomething/123a 

JSON響應:

{ 
    "dosomething": { 
     "status": "ERROR", 
     "errors": [ 
      "Value passed: |123a| must be a integer." 
     ] 
    } 
} 

再次我的問題是,我應該轉嫁請求200或400 HTTP狀態,其中傳遞的參數是不是我有什麼期待?或者應該在請求正在工作時總是200響應?

什麼被認爲是最佳實踐?

回答

5

使用404.總是。 404.否則就會誤解URI和資源的性質。如果http://blah.com/api/v1/dosomething/標識了該資源,並且123a僅僅是它的一個參數,那麼其他代碼可能是有意義的。但它不:http://blah.com/api/v1/dosomething/123標識資源。如果不存在此類資源,請返回404 Not Found

您可能擁有一些實施細節,處理資源http://blah.com/api/v1/dosomething/123http://blah.com/api/v1/dosomething/123a,但它不是資源。從Roy Fielding的dissertation:。

「的資源沒有存儲對象的資源不是服務器用於處理存儲對象 機制 資源是一種概念上的映射 - 服務器接收標識符 (其標識映射),並將其應用於其當前映射 實現(通常是特定於集合的深度樹 遍歷和/或散列表的組合)以找到當前負責的處理器實現,然後處理器實現選擇 根據請求內容採取適當的行動+迴應所有這些 特定於實現的問題隱藏在Web界面後面; 其性質不能由一個客戶端,只有通過Web界面訪問 承擔。」

-2

HTTP 400用於表示HTTP請求本身存在問題(例如無效的HTTP標頭)。儘管您沒有收到您期望的參數,但該請求仍然是有效的HTTP請求,因此我會返回200響應,但在JSON中包含缺少參數的詳細信息。

+0

這是一個常見的誤區。400是客戶端應用程序錯誤,因此它可以代表失敗的案例的整個範圍。最新Httpbis規範改變了400錯誤的措辭,以顯示它可以更廣泛地應用http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-19#section-7.4.1 –

4

通過作者編輯:422是一個錯誤的答案。我誤解了最初的問題並給出了無效的答案。請參閱@fumanchu的回覆:https://stackoverflow.com/a/10955717/441250我在下面的回答是錯誤的。

我建議使用「422 Unprocessable Entity」,並在響應正文中包含失敗信息。

的422(無法處理的實體)狀態代碼表示該服務器
理解請求實體(因此一個
415(不支持的媒體類型)狀態代碼是不適當的)的內容類型,並且
語法的請求實體是正確的(因此400(錯誤請求)
狀態碼不合適),但無法處理包含的 指令。例如,如果XML請求主體包含格式正確(即語法上正確),但XML語義錯誤的XML指令,則可能出現此錯誤情況。

在處理錯誤時使用「200 Ok」或任何其他狀態代碼是不可接受的。

P.S. 狀態碼列表: http://www.iana.org/assignments/http-status-codes/http-status-codes.xml

+0

所以有一個正確的HTTP狀態來響應,如果我使用1.0或1.1 HTTP協議版本,這有什麼關係嗎? –

+1

菲爾:沒關係,但是 - 在這種情況下 - 422根本不是正確的響應。啓動器,請求中沒有有效載荷(請求實體)。 (422可能是其他情況下的正確答案) –

+0

@朱連你說得對,我誤解了最初的問題。 Phill 422是不正確的狀態代碼使用,我假定你正在執行寫操作。 – ioseb