REST - 發送部分無效請求時拋出什麼錯誤

我正在開發REST API。爲了簡化我的問題，我有一個API，允許人們創建一個新的博客帖子。REST - 發送部分無效請求時拋出什麼錯誤

博客帖子可以存在於類別中，並且類別由類別ID指定。如果用戶提供一個不存在的category-id，哪個HTTP錯誤代碼是最合適的？

404 for Not Found似乎不好，所以我現在用了400個壞請求。有更好的嗎？

2009-07-06 Evert

不是這個問題的答案，但是如果您的API用於博客，那麼您可能會更好地實施MetaWebLog API（http://www.xmlrpc.com/metaWeblogApi）或Atom發佈協議（http： //tools.ietf.org/html/rfc5023），所有常用的博客工具都可以發佈到它。 – 2009-07-06 20:05:42

我也肯定會和Atom一起去，我的服務並沒有真正與博客聯繫在一起。我只是想這是一個很好的例子 – Evert 2009-07-06 20:26:48

我假設您在回覆博客文章資源上的PUT或POST請求。

因爲您使用URI訪問的資源被找到，所以我會使用400。如果請求內容正確，博客文章可能已被修改。

由於這是發送的查詢的內容是錯誤的，而不是資源的實際URI，我會堅持400錯誤。

但是，如果您正在通過PUTting或POSTing將類別中的博客文章添加到類別中，則可以返回404 Not found。

來源

2009-07-06 19:52:18

我認爲404 Not Found是最合適的回答 - 考慮客戶試圖訪問一個不存在的類別，所以完美的答案是「我找不到那個類別！」

來源

2009-07-06 19:48:13

404有一個非常具體和常用的含義，即URL找不到。此外，一些瀏覽器將使用自己的404錯誤頁面，使事情更加混亂。參見http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

我建議「406不可接受

該請求所標識的資源只能能夠產生具有根據在請求中發送的接受報頭，內容無法接收響應實體。」

400雖然不壞。

來源

2009-07-06 20:13:18

409 Conflict這是應用程序特定的違規規則嗎？在這種情況下，博客帖子的類別ID必須已經存在。當您返回409衝突回覆時，請確定用戶可以採取哪些措施來糾正情況，以便他們可以重試POST/PUT。

來源

2009-07-07 18:05:21

我同意Vincent，因爲在可用的已定義狀態碼中，400是最好的。客戶端應該知道在提交請求時類別id是否有效，因此向服務器提供錯誤的請求內容。

對於一些其他的答案提供：

404未找到 - 這是不使用正確的狀態，因爲資源你發送請求到真正被發現 - 這是隻是提供的資源中找不到的引用資源。
406不可接受 - 此狀態與Evert註釋一樣，與Accept標頭一起使用;請參閱第10.4節。RFC2616 7：

該請求所標識的資源只能能夠產生具有根據在請求中發送的接受報頭不能接受內容特性響應實體。
409衝突 - 此狀態旨在用於資源衝突狀態，通常是由於可能通過其他渠道或線程修改了資源。該RFC（第10.4.10）給出了一個例子：

...如果版本是被利用和被投入實體包括改革資源與那些由早些時候衝突（第三方）的請求，服務器可能會使用409響應以表明它無法完成請求

HTTP確實提供給400的替代 - 如果配件，您可以創建這種情況下你自己的4xx狀態。在RFC的6.1.1節中：

HTTP狀態碼是可擴展的。 HTTP應用程序並不需要了解所有已註冊的狀態代碼的含義，儘管這樣的理解顯然是可取的。

因此，您可以定義自己的自定義「430 - 未找到引用的資源」或類似的東西。遵守HTTP的客戶端應該，如果他們不知道這種狀態，將它視爲400，但是如果客戶端專門針對API編碼，他們應該能夠將其作爲430處理並適當地使用它。

來源

2009-07-07 18:50:35

REST - 發送部分無效請求時拋出什麼錯誤

回答

相關問題