0

I've got an HTTP POST method that has numerous validations. Some mean the request is flat out invalid, and we return a 400 Bad Request.

However, for some of them, even in the case of the request being invalid, we need to create a resource and return a representation in the body. What would be the correct status code to use?

200 OK seems wrong because the request was invalid

400 Bad Request seems wrong because we have created a resource as a result

Edit: the request is to link two objects in the system, in this case a member to a ticket. However, even if the request is invalid, for example because the ticket is already assigned to another member, we want to store a record of the request against the ticket in a 'ticketLink' table with a status of 'ticket-already-assigned', and return that validation message in the response.

GoatInTheMachine
  • 3,583
  • 3
  • 25
  • 35
  • You should check this https://stackoverflow.com/questions/942951/rest-api-error-return-good-practices – lauda Jul 12 '17 at 15:55
  • Possible duplicate of [REST API error return good practices](https://stackoverflow.com/questions/942951/rest-api-error-return-good-practices) – lauda Jul 12 '17 at 15:55
  • 1
    "However, for some of them, even in the case of the request being invalid, we need to create a resource and return a representation in the body." That's really _weird_ -- you should improve your question by including more details explaining these circumstances. – VoiceOfUnreason Jul 12 '17 at 15:57

1 Answers1

1

the request is to link two objects in the system, in this case a member to a ticket. However, even if the request is invalid, for example because the ticket is already assigned to another member, we want to store a record of the request against the ticket in a 'ticketLink' table with a status of 'ticket-already-assigned', and return that validation message in the response.

Short answer: 200.

Slightly longer answer

The POST method requests that the target resource process the representation enclosed in the request according to the resource's own specific semantics.

Since the API did that, successfully, the correct way to signal this is 200 with a content body providing additional information.

As is often the case in REST - the correct analog to use is that of a web site. Human being fills out a form, and hits the submit button to apply for a ticket. What comes back is an HTML document saying, "we're sorry, that's no longer available, here are some links to other options."

The status code 200 signals to the browser (and the intermediaries) that the document transport was successful.

The 4xx series all indicate that there was an error in the document transport; specifically that the request sent by the client was broken in some way. That's not the case here (where you are dealing with an error in the domain model).

Frankly, it's not even an error in the domain model, right? The model's not supposed to let you claim a ticket that has been claimed by somebody else; so it did the right thing.

The REST API consumer uses the message in the response, not the transport status code, to understand what the result of the processing was, and what protocols are now available.

VoiceOfUnreason
  • 52,766
  • 5
  • 49
  • 91