一個415錯誤響應適當以RESTful web應用程序

我建立一個網絡應用程序，它可以通過PUT，在這兩個x-www-form-urlencoded和JSON格式POST和PATCH接受資源表示。如果我以另一種格式收到申請機構，我想發送一個415響應，以及一些額外的數據，聲明我接受的格式（與405響應的必需Allow:標題類似）。我在HTTP 406 and 415 error codes上看到過一個答案，在那裏回答的人不知道是否有這樣的機制定義，RFC 2616在這方面沒有提及任何內容，有些粗略的谷歌搜索也沒有提到。一個415錯誤響應適當以RESTful web應用程序

我想僅僅使用Accept:即使它被定義爲請求標頭。這似乎是最恰當的，只是重新使用它的這種反應。人們同意嗎？有沒有人有更好的建議？

編輯︰我從那裏發現Specify supported media types when sending "415 unsupported media type"哪些問具體是否有一個這樣的標準。正確和被接受的答案基本上是沒有，但那裏的響應者也有和我一樣的想法，即Accept將是一個很好的頭來用來提供這些信息。這提示a message從Julian Reschke到HTTP工作組詢問是否應該定義在響應中發送Accept:標頭的意思。該電子郵件只收到一個答覆，該答覆認爲這是必要的，而Accept似乎是恰當的。

需要注意的是我，如果我允許發送Accept頭不是問，任何頭被允許在任何一個方向發送，但只有在規範中定義的具有意義（語義）到中介機構，並且任何未預先加上前綴X-的意外標題都可能與將來的HTTP版本衝突。這並不妨礙我。

來源

2012-11-07 Nicholas Shanks

我所有未解決的問題仍在等待可接受的答案。我很想看到發佈給他們的新答案。 –

那麼也許你應該提出可以以可接受的方式回答的問題。 – 2012-11-08 12:10:39

正如你所說，Accept是一個請求頭。這是錯誤在迴應中使用它。

要quote Wikipedia，

內容協商是在於使得可以服務於相同的URI的文件的不同的版本（或更一般地，資源表示）的HTTP規範中定義的機制，使用戶代理可以指定哪個版本最適合他們的功能。

所以它是客戶誰在請求什麼媒體類型，他可以Accept說。如果服務器無法傳送此媒體類型，他會以406 Not Acceptable作出響應。

由於客戶端必須能夠處理所請求資源的返回表示，因此應該指定它可以理解的媒體類型。它，可以指定多個媒體類型：

Accept: application/json, application/xml, x-www-form-urlencoded

如果客戶真的要接受任何媒體類型，它可以設置

Accept: */*

服務器將設置一個適當的Content-Type響應頭甚至這樣的請求。

來源

2012-11-08 08:03:38

_「因此，客戶在請求中說什麼他可以接受的媒體類型，如果服務器無法傳遞這種媒體類型，他會迴應415不支持的媒體類型。」 - - 但問題是_server_可以如何迴應說它不理解給定的「內容類型」。 – CodeCaster

服務器通過將狀態設置爲415.你想要的是服務器告訴它*可以理解的內容。 HTTP中沒有這種方法。 – 2012-11-08 08:45:59

@Tichodroma否，@CodeCaster正在糾正你的答案中的錯誤。你說：「如果服務器不能傳送這種媒體類型，他會用'415 Unsupported Media Type'來響應。」如果服務器不能滿足Accept請求頭的條件，它應該發送'406 Not Acceptable'。在我描述的情況下，415的回答是正確的。 –

您收到的無法識別的Content-Type很可能來自當前正在爲您的服務實施客戶端的開發人員。由於不存在服務器通告其支持的內容類型的機制，因此您最好在消息體中提及您支持的類型。

來源

2012-11-08 08:19:11 CodeCaster

我不知道任何標準的機制來做到這一點的，但你可以稍微再目的候補頭http://www.ietf.org/rfc/rfc2295.txt做你想做什麼。

來源

2012-11-09 12:33:32

我不明白這是如何工作的。 Alternates提供其他表示的URI。我正在尋找一種方法來告訴客戶它的請求體應該採用什麼格式。如果你想進一步解釋你的想法，請回答你的答案。 –

一個415錯誤響應適當以RESTful web應用程序

回答

相關問題