21

I have service that takes some entity and needs to save/update this entity:

http://myhost.com/rest/entity

I use POST and submit JSON. Inside service it detects that entity passed is not good. Not valid, order passed in with customer that doesn not exist, etc.

How should I reply? HttpCode.NotFound? Or others? How do you reply to such things?

katit
  • 17,375
  • 35
  • 128
  • 256
  • 1
    Well, that is realy up to you to decide, it's your service. – jgroenen Jan 20 '12 at 15:59
  • possible duplicate of [REST HTTP status codes for failed validation or invalid duplicate](http://stackoverflow.com/questions/3290182/rest-http-status-codes-for-failed-validation-or-invalid-duplicate) – MaxiWheat Dec 03 '14 at 16:13

3 Answers3

35

422 Unprocessable Entity, defined in WebDAV (RFC 4918):

The 422 (Unprocessable Entity) status code means the server understands the content type of the request entity (hence a 415(Unsupported Media Type) status code is inappropriate), and the syntax of the request entity is correct (thus a 400 (Bad Request) status code is inappropriate) but was unable to process the contained instructions. For example, this error condition may occur if an XML request body contains well-formed (i.e., syntactically correct), but semantically erroneous, XML instructions.

Julian Reschke
  • 40,156
  • 8
  • 95
  • 98
  • 4
    I really like this. It's probably going to be unpopular with the purists but it is way better that using the same status as a malformed request. – thomas-peter Sep 04 '13 at 08:49
  • On the project I'm working on I was also very bothered by the inability for the client to distinguish between validation errors and malformed requests from the status code alone (w/o inspecting response body), and independently thought of using 422 to distinguish the former. I came across this while doing some sanity-check searching to make sure there weren't better alternatives, so I'm glad to see other people have used this approach and that this isn't completely out of left field. May I presume neither of you encountered other downstream issues with this approach? – rscarter Feb 17 '18 at 20:27
  • This is what I do since the common use of 400 is really not technically correct given that the request isn't bad. – Emmanuel Mar 05 '20 at 01:40
26

In our project in such situations we do the following:

  1. Set response code to HTTP 400 Bad Request
  2. Set response body to the following JSON: {"message":"%extended error message here%"}

But it's really very subjective.

Also I'd suggest reading This blog article on RESTfull error handling - it describes many available options, so you can choose something for your taste.

Dawie Strauss
  • 3,706
  • 3
  • 23
  • 26
Sergey Kudriavtsev
  • 10,328
  • 4
  • 43
  • 68
  • 1
    This is what we do. We return the same media type asked for if available. In the web world you get back a 400 with text\html. In this example the media type is application\json – suing Jan 20 '12 at 16:12
  • Thank you! I was thinking about passing some info in header in addition to status code but between article you referred and this posts I think I will decide on common response object for my services and only use 400 and 200 codes (Other than 401 for auth) – katit Jan 20 '12 at 16:16
  • if you're going to return validation errors then 400 is sufficient – jim smith Oct 18 '18 at 02:46
0

I think you should pick a client error code. 400 Bad Request or 403 Forbidden can be a good start

parapura rajkumar
  • 24,045
  • 1
  • 55
  • 85