Is it correct to return 200 Ok HTTP status for a POST request?

Question

Usually, we use POST to create a resource on the server-side.
So ideally if everything goes right, the server should respond either with a 201 Created HTTP status or in case of an asynchronous operation with 202 Accepted HTTP status.

Is there any valid scenario where a POST request can be returning a 200 OK HTTP status?
Or should we never use 200 OK HTTP status for a POST request?

Solution 1

I see 200 as a very common response to POST requests on internet. It's fine to use it.

From RFC 7231:

6.3.1. 200 OK

The 200 (OK) status code indicates that the request has succeeded. The payload sent in a 200 response depends on the request method.
For the methods defined by this specification, the intended meaning
of the payload can be summarized as:

GET a representation of the target resource;

HEAD the same representation as GET, but without the representation data;

POST a representation of the status of, or results obtained from, the action;

PUT, DELETE a representation of the status of the action;

OPTIONS a representation of the communications options;

TRACE a representation of the request message as received by the end server.

And section 4.3.3:

Responses to POST requests are only cacheable when they include explicit freshness information (see Section 4.2.1 of [RFC7234]). However, POST caching is not widely implemented. For cases where an origin server wishes the client to be able to cache the result of a POST in a way that can be reused by a later GET, the origin server MAY send a 200 (OK) response containing the result and a Content-Location header field that has the same value as the POST's effective request URI (Section 3.1.4.2).

Solution 2

Yes, You can return 200 Ok HTTP status, but you SHOULD return a response BODY.

In general, we have 3 options according to your API requirements:

1. Return 201 Created HTTP status, with EMPTY BODY.
   In case you don't need to return a response body.

2. Return 200 Ok HTTP status, with BODY.
   In case you need to return a response body [containg created resource].

3. Return 202 Accepted HTTP status, with EMPTY BODY.
   In case the action will be queued.

Comments

[DesirePRG]

but can we call it a restful approach in case if we are using it to develop an API?

[Gabe Sechan]

@DesirePRG Sure, why not? RESTful is a description of the architectural properties of a remote API. It doesn't even need to use HTTP to be RESTful, much less use specific return codes.