1

My route, POST /items, saves items, which show up in the payload.

The client would like items to save even if others do not.

Example:

POST /items with a body of [1,2].

1 saves, but 2 does not due to a client-side error.

In this event, it seems worthwhile to return an HTTP-400 since 2 is invalid due a client error, i.e. invalid item ID.

Example 2:

POST /items with a body of [1,2].

1 saves, but 2 does not due to a server-side error.

In this event, it seems worthwhile to return an HTTP-500 since 2 is invalid due a client error, i.e. invalid item ID.

Example 3:

POST /items with a body of [1,2,3].

1 saves, but 2 does not due to a server-side error. 3 fails to save due to a client-side error.

What's the appropriate response here? Does the existence of a server-side error trump the client-side error, i.e. HTTP-500 is appropriate?

In all cases, the response payload would include successes and failures.

Do these HTTP response codes make sense? If not, what's the REST-ful alternative?

Kevin Meredith
  • 41,036
  • 63
  • 209
  • 384
  • Yes. 4xx if the error is because of the data issues, and 5xx if the error is because of internal server. – Husain Oct 24 '16 at 12:35
  • Thanks - I updated my question with a third example per your comment. – Kevin Meredith Oct 24 '16 at 12:37
  • Example 3 is very tricky. If you want your endpoint to exit as soon as possible, then you return 500 when you process input 2. If you want to process all of them an return, then either 4xx or 5xx make sense. But if you return an error message, then it has to indicate why the particular error is raised. – Husain Oct 24 '16 at 14:28
  • You can take a look in multi status responses. Read [this question](https://stackoverflow.com/questions/45442847/rest-api-response-in-partial-success). – ScottSummers Aug 13 '18 at 12:49

0 Answers0