Which status use when iterate into the same request? - rest

Question

I have a concern about which status code need to use in the following scenario:
Suppose that I have the following endpoint:
https://my-restaurant.api.com/v1/orders
And I made a POST request with some elements inside of the body to start a new order:
{
date: "2018-08-10T09:00:00.000-03:00",
order: 12345
}
The response would be the following:
{
require_additional_data: true,
customers: [],
waiter: "Jon Doe"
}
Here, the service tells that need more data before to close the order. The next step would repeat the request with the same body, but with more data about the order.
The response status code should be a 200 OK in this case? I guess that would be 200 OK once that the service tells that order was finished and have all the information required.
Until that, which status code would be used?

Answer 1

Don't use 200 for this situation. Keep in mind that 2xx status codes indicate that the request was successfully received, understood, and accepted by the server. That's not your case.
A 4xx status code would be more suitable for the situation described in your question. You could use 422 as pointed in the comments. It indicates that the request entitity cannot be processed due to semantic errors (but it's sintatically correct). See the definition below:
11.2. 422 Unprocessable Entity
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.

Answer 2

It depends on the state cycle or constraints of your order ressource :
Can an order resource (in your database or any persistence layer) be empty?
If yes, you should return 200.
If no, you should return a 400 Bad request. You can also return a 422 who will be more precise.
Both are good answers.
If creating an order is for you a long process, which need multiple requests, then an order could be empty.
e.g. :
Create empty order
Add first meal
Add second meal
Add wine
If creating an order is one atomic request, or you don't want to see any empty order in your base the order cannot be empty.