考慮到REST API的調用：處理API的多個響應代碼的好方法是什麼？
POST /employees
[{ "name":"joe", "job":"dev",
{ "name":"bob" }]
對於僱員將被創建的每個數組元素。但是，作業是必填字段，因此第二個元素無效且不能創建員工。
對此有什麼好的迴應？ 201或422？
我看到207，但它似乎需要XML響應，並且API不使用XML。僅僅爲這種情況返回XML似乎很奇怪。
對於這個特殊的用例，我想所有有效的元素都會被用來創建資源。但我不確定會有什麼好的迴應。
一種方法是有一個批處理程序。因此，您可以在一個HTTP請求中發送一批操作，但是它們會作爲針對服務器上的api的單獨操作進行處理。因此，批處理響應將包含針對每個單獨操作的適當響應代碼。
批處理請求還可以包含更改集以定義事務行爲。
您的批次還可以根據需要包含對不同操作的調用。
你沒有說明你是如何構建你的api的。如果使用ASP.NET Web API，則可以使用批處理功能。
FWIW，它是一個Rack API。 –
對於任何字段驗證錯誤（包括缺少必需字段），無論是單個資源還是整個集合，我們都使用400。
我不完全確定你在做什麼。
爲了發生某些事情，整個有效負載應該是有效的，而不僅僅是部分。所以我不會處理有效載荷的有效部分。
我不會使用任何2xx狀態，因爲這會告訴用戶，一切正常，這在這種情況下是不正確的。
我不會返回400狀態，因爲有效負載的語法在語法上是正確的JSON，但在語義上是錯誤的。
這會讓我們留下一個422狀態，這在這種情況下更合適，因爲就像我之前所說的那樣，你有語義而不是語法問題。
這是一個有趣的觀點。所以，你確實說問題是處理部分請求。也許這是一種反模式。但我認爲有些情況下它是有道理的......然而，臭的部分是你如何讓客戶知道只有零件被處理了，哪些零件是無效的。 –
只處理部分有效負載很可能會在您的用戶羣中造成更多混淆。我建議不處理任何東西，如果'工作'字段丟失，並返回一個包含描述性錯誤信息的主體的422狀態。正文可以是一個json數組，因此在必要時可以包含多個錯誤消息（_例如多個條目缺少fields_的集合）。 –
什麼API？你自己的API？ – visc
您可以接受員工的批量發佈並返回錯誤響應代碼（如果只有一個錯誤）。或者，我會做什麼，寫一個接口，一次只需要一名員工。然後你可以有個人迴應代碼。對於小型字符串數據，您不必擔心性能或速度。 – visc
我會避免201一個批量發佈，因爲這可能會給你的API的用戶一個錯誤的成功感。 – visc