2014-11-04 19 views
3

例如,我可能希望返回資源的當前序列號,並且對版本化資源的HEAD請求做出409響應,但由於HEAD不允許,因此我可能不會在響應實體中提供它。另一個例子:假設由於版本衝突,對提交端點的POST請求失敗。我可以用409響應,但有時我可能想另外通知客戶它正在提交的事務已超出最大重試次數,並且進一步的嘗試將不會成功。我可能會返回HTTP/1.1 409 Conflict/final,而不是在這種情況下只有HTTP/1.1 409 Conflict。我的問題是,這是可接受的做法嗎? HTTP 1.1 RFC沒有爲這個問題提供明確的答案。可以將語義信息放入REST API中的HTTP原因短語中嗎?

我知道我可以把這些信息放在一個X-...的HTTP頭中,或者以某種方式在響應實體中包含這些信息(額外的XML標籤或JSON屬性等)假設我不能或不想做所以如果我能幫助它。

回答

1

原因詞組很可愛,用於調試;但就是這樣。它在HTTP/2中消失了,並且可能被中介和/或軟件庫丟失;不要依靠它被保存。

-1

HTTP響應的格式是

狀態行= HTTP版本SP狀態碼SP原因短語CRLF

按照該規範,在此原因短語可以是定製。您可以添加您的版本的錯誤消息。請檢查這裏http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html。它提到

這裏列出的短語的原因只是建議 - 它們可能會被本地等價物替換而不會影響協議。

+1

RFC是我第一次閱讀的內容。我認爲「本地等值」是指一個德國服務器說「404 Nicht Gefunden」而不是「404 Not Found」。目前還不清楚我是否可以在那裏提供語義信息,或者這是否是一個好主意。 – 2014-11-04 10:33:16

+0

請不要再引用RFC 2616。 – 2014-11-04 11:58:29

+0

@JulianReschke真誠的問題:我們應該看什麼而不是RFC 2616? (我在與OP相同的問題上登陸此頁面,在我到達此處之前也閱讀了RFC 2616)。 – 2015-12-29 15:05:39

相關問題