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?
HTTP Status Code 200: The "OK" ResponseAn HTTP status code 200 means success. The client has requested documents from the server. The server has replied to the client and given the client the documents. All is well.
The POST method is used to send data to the server. Perhaps the most common status code returned is 200. It simply means that the request was received, understood, and is being processed, whereas the 201 status code indicates that a request was successful and a resource was created as a result. 1.
The 204 (No Content) status code indicates that the server has successfully fulfilled the request and that there is no additional content to send in the response payload body. While 200 OK being a valid and the most common answer, returning a 204 No Content could make sense as there is absolutely nothing to return.
If there is NOT a new version number: The 200 or 204 HTTP status code would fit well. If there is no benefit to the client knowing the version number has changed or is the same: Send the 200 HTTP status code.
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).
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:
Return 201 Created
HTTP status, with EMPTY BODY.
In case you don't need to return a response body.
Return 200 Ok
HTTP status, with BODY.
In case you need to return a response body [containg created resource].
Return 202 Accepted
HTTP status, with EMPTY BODY.
In case the action will be queued.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With