Odpowiedź Bulk API w przypadku błędu

JSONowe API wygląda następująco:

POST /orders

[ {name: "Name 1"}, {name: "Name 2"} ]
API ma zapewnić transakcyjność - zapisane jest wszystko albo nic.
W przypadku gdy rekordy są poprawne dostajemy:

[ {id: 1, name: "Name 1"}, {id: 2, name: "Name 2"} ]
Moje pytanie: w jakiej formie najlepiej zwrócić odpowiedź gdy walidacja któregoś obiektu nie przejdzie?
Będą potrzebne błędy walidacji dla konkretnych obiektów oraz informacja, że reszta jest poprawna.
Znacie jakieś dobrze zaprojektowane API tego typu?
Poniższe rozwiązanie ma swoje minusy:

[ {name: "Name 1"}, {errors: {name: "blank"}} ]
PS
Frontend jest w Backbonie

Zajrzyj tu: http://en.wikipedia.org/wiki/List_of_HTTP_status_codes ale wydaje mi się że nie znajdziesz nic co by pasowało do Twojej sytuacji. Zastanowiłbym się nad zmianą podejścia i zwracaniem jakiegoś statusu w treści JSONa zamiast odpowiedzi. W takim wypadku zwracałbym zawsze 200 OK w HTTP, informacje o powodzeniu / niepowodzeniu miałbym we własnych statusach. Byle by być konsekwentnym i stosować albo jedno, albo drugie rozwiązanie.

Błagam, nie róbcie tego :frowning:

Kolega Chastell mógłby więcej opowiedzieć o “fajnych” API które ZAWSZE zwracają 200, ale potem trzeba sprawdzić zawartość jsona żeby zobaczyć czy to było “200 OK oto dane o które prosiłeś” od “200 OK pierdol się”.

Niech oblana walidacja zwróci 400 albo 422. Ewentualnie 403. Albo nawet 500. Wszystko, tylko nie “200 OK terefere”.

Zwracałbym 422 - jak pisałem wcześniej, zapisujemy wszystkie obiekty albo żadnego, więc można traktować całe zapytanie jako niepoprawne.
Bardziej chodzi mi o plusy/minusy treści odpowiedzi, tak aby można było z niej wygodnie skorzystać.
Poza tym nie chciałbym wymyślać koła od nowa, bo wydaje się to być częstym elementem API, aczkolwiek nie mogę nic adekwatnego znaleźć.
Skłaniam się do zwracania pustego obiektu w przypadku poprawności i obiektu z błędami w przeciwnym:

[ {}, # ten jest poprawny {errors: [name: {"blank"}]} # ten nie ]

backbone.js działa tak, że w przypadku prawidłowego zapytania (2xx) trzeba zwrócić zapisany/zaktualizowany rekord, nie orientuje się jak działa domyślnie w przypadku otrzymania nagłówka błędu.

Najlepsze api ever, jeśli chodzi o architekturę, to moim zdaniem api githuba.

Ja bym zmodyfilował to: http://developer.github.com/v3/#client-errors

[code] HTTP/1.1 422 Unprocessable Entity
Content-Length: 149

{
“message”: “Validation Failed”,
“errors”: [
{
“resource”: “Issue”,
“field”: “title”,
“code”: “missing_field”
}
]
}[/code]
P.S. też nie znoszę jak coś zwraca zawsze 200 :D. A już najgorsze co widziałem to smsapi, które czasem zwraca odpowiedzi w plain text w stylu “OK”.

@sarniak API Githuba to był mój pierwszy krok :wink:
Nie mają oni jendak elementów Bulk/Batch (która nazwa jest bardziej trendy obecnie?)
Nie chodzi mi o struktruę konkretnych błędów, a o całościową odpowiedź z zachowaniem kolejności przesyłanych obiektów.