什麼Http代碼應該返回「找不到」？

Question

我正在構建一個網絡服務，在這種特殊情況下，用於詢問有關贊助人的信息。

比方說，因爲參數的緣故，查找網絡命中：

GET /patrons/619 HTTP/1.1 

如果找到了靠山，我返回碼200：

HTTP/1.1 200 OK 

如果省略，或給一個不是數字的帳號，我返回400.例如下面的錯誤請求：

GET /patrons HTTP/1.1 
GET /patrons/ HTTP/1.1 
GET /patrons/G619 HTTP/1.1 
GET /patrons/kirsten%20guyer HTTP/1.1 

全部返回錯誤400（無效請求），例如：

HTTP/1.1 400 Invalid patron number 

---

我想有一個狀態代碼靠山沒找到，返回HTTP狀態代碼。例如：

GET /patrons/1322 HTTP/1.1 

HTTP/1.1 404 Not Found 

我想過使用404（未找到），這是有效響應（所請求的資源是真心的，忠實地，沒找到。）但我怕調試它的人可能會認爲這意味着他們拼寫錯誤了/patrons/錯誤。

任何人都可以想到我可以使用另一個http狀態碼嗎？

---

更新：我我目測

204 No Content 
The server successfully processed the request, but is not returning any content. 

說你什麼？

---

不要忘了，並非所有的HTTP服務器都提供HTML內容。如果IIS Web服務器請求一個叫做資源：

GET /MyStartPage.html HTTP/1.1 

然後HTTP服務器必須決定如何迴應。在大多數網絡服務器上，名爲/MyStartPage.html的資源對應於位於硬盤驅動器上的文件。

鑑於StackOverflow的作用：

GET /posts/1027301 HTTP/1.1 

其中，如果資源不存在，網絡服務器應該（正確）返回404

Answer 1

404找不到是正確的返回，如果它是服務，它不是真的被人類使用，而是被機器使用，因此，錯別字不應該是您的首要關注點。

此外，您無論如何都不會有能力去抵制人類行爲（想想一件事情，當它真的是另一件事情時）。如果你在錯誤代碼中返回一個小錯誤信息，一切都應該解決。你甚至可以向他們建議一個可能的解決辦法。

當應用程序正在做它設計的功能時返回500也似乎有點奇怪。 404描述了這種情況：資源未找到。

Answer 2

恕我直言，HTTP響應是不的處理這個問題的適當位置，因爲錯誤不在HTTP級別。它在應用程序級別。一種可能的解決方案是使用Null Object Pattern返回一個符合Patron接口的空'贊助人'，但表示不存在這樣的人。

---

更新：我一直相信這個答案是錯的。不過，我想留下它，因爲它是一個潛在的有效答案（取決於問題中未提供的細節），我認爲這些評論是有啓發性的。

Answer 3

通常，如果您的服務遇到無法處理的錯誤，但請求格式正確，那麼我認爲您想要返回500狀態碼。另外，爲什麼我說500會是合適的另一個原因是，從我在.NET Web服務中的經驗來看，無論何時我通過線路引發異常（例如RecordNotFound異常），Web服務器和客戶端總是會解釋該響應是一個500狀態碼。

無論採用哪種方式，最好查看http狀態代碼的這個list，並對最適合您的需求進行優化。

Answer 4

對於這種情況，錯誤404實際上是更可接受的響應，因爲找不到資源。您始終可以擁有一個自定義錯誤文檔，說明它是沒有找到的贊助人ID。

400錯誤意味着客戶端發送格式錯誤的語法，在您的示例中不是這種情況。因此，你不應該使用這個錯誤代碼。看起來「錯誤的請求」是準確的，但這實際上意味着請求頭語法中存在錯誤。

這也不是500錯誤，因爲沒有發生錯誤。 Web服務器完成請求沒有問題，事實是請求正在尋找一個不存在的資源。

404是唯一適當的迴應，除非你要認爲這是一個完全有效的請求，返回狀態200，並解釋說，要求贊助不存在的頁面。

從我原來對這個問題的評論：

我不認爲一個200級的錯誤將是合適的或者，考慮在W3 w3.org/Protocols/rfc2616/rfc2616-sec10.html

Answer 5

我想解釋你應該使用API​​的開發者404會明白404點的手段，因此將遵循有自己平常的調試過程中，爲了解決這個問題。堅持協議。

Answer 6

錯誤在Web服務水平不應該只返回一個簡單的HTTP狀態行，但可以通過客戶端訪問服務的解析的有效和記錄格式應該改爲返回的內容。返回的文檔應包含一個錯誤代碼，該代碼是特定於您的Web服務的一組文檔的一部分，以及問題的簡短說明以及可選的更詳細的問題描述。

Answer 7

這取決於你正在構建哪種類型的web服務。

SOAP和XML web服務通常返回200 OK，如果所請求的對象（守護神）不能被發現和編碼錯誤類型/消息/描述成響應文檔。它們將傳輸級別（HTTP）與交換的消息（XML）分開。如果您請求不存在的API端點（錯誤的URL），則僅返回404錯誤（位於傳輸級別）。

隨着REST Web服務但是，使用HTTP的方法和狀態的直接信息交換。 REST使用不同的HTTP方法（GET/POST/PUT/DELETE）來指定要執行的操作，並且服務器將狀態作爲HTTP狀態返回。因此，如果REST網絡服務，如果無法找到顧客，404將是正確的HTTP狀態。

500是不合適的，我認爲，因爲5xx意味着在服務器端出現了問題（情況並非如此），而4xx錯誤則意味着客戶端有問題。

Answer 8

如果您想通過HTTP響應代碼控制的Web服務的響應，那麼你確實可以用404來表示這種情況。

但是，我認爲讓web服務的響應完全定義在HTTP響應的主體中更爲自然，並且爲了成功的通信返回200（「我理解了您的請求併發送了適當的響應」 ）。在這種情況下的話，你會回到200爲正常您的要求（XML或JSON或其他）的有效載荷，表明沒有匹配找到實體

我會考慮類似於傳統的例外非200錯誤代碼編程語言和HTTP響應體更像返回代碼。想象一下，如果你正在按照慣例執行 - 如果沒有找到實體，你會拋出異常，還是返回null？就個人而言，給定的網絡連接的脆弱性，我希望保留所有的HTTP級的錯誤代碼的通信問題，我有一個有效載荷寧願始終從服務本身返回200 OK，沿着指定的結果或任何服務級錯誤。

Answer 9

這可能是4歲，但它仍然是相當有關。對於要同時使用的API和本地應用程序的API，我發現使用HTTP代碼進行狀態指示要簡單得多。如果需要的話，可以使用未分配代碼中的一些額外代碼，以適應不適合現有HTTP代碼的條件。