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?
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.
Related
In case of success of HTTP GET entire collection (ex. /users) or specific item (Ex. /users/123), we send 200 (OK).
In case of (HTTP GET) specific item's ID not found or invalid we send 404 (Not Found).
What response should we send in case of (HTTP GET) entire collection not found or invalid?
What response should we send in case of (HTTP GET) entire collection is empty?
Say for example, I created a flow for scatter-gather and I want to check if all endpoints are returning same result status code 200 or throw an error if not.
Configure the Response Validator (General > Response > Response Validator) for each HTTP Request so only 200..299 responses are considered valid.
You can use try block for every HTTP request on wrap whole scatter gather. If one fails, capture HTTP status code in on error propogate and log the results.
I suggest you wrap each request into try block, if you already have a global error handler defined, it should pick up status code 500 etc. Otherwise, capture response code into dataweave
How can I get response code from navigator.sendBeacon? I need to have some indicator that can say me that request is failed? Particularly, I am looking for a way to identify bad request (request that was send with “bad” malformed json and got 4xx response code). Is there any way to do it while using sendBeacon?
From documentation:
The sendBeacon() method returns true if the user agent is able to
successfully queue the data for transfer, Otherwise it returns false.
So, it is not returning false if request is invalid.(and response code is 4xx)
navigator.sendBeacon(that.sushiEndpoint, sushiPayload)
Today I came across a scenario where there was a POST method call but that does not require a request data and query parameters are sufficient. But in Karate framework it is mandatory to give request data when it is POST method. So I had to provide request as 'null' explicitly. Is there any way in Karate that if there is no request data then you can skip providing request data as 'null'.
This is what I usually do if there's no request body :
Given path '/path/to//action'
And request ''
When method post
Then status 200
(Haven't found a way to skip the request step)
I tried this way:
Given url 'url'
And params param_value
And request '{}'
When method post
Then status 200
Its same as mentioned above just I gave empty request body
I'm writing a microservice for validating promo codes. The client sends me a promo code and a product ID (json). There is the 200 OK case where the code is good, I apply a discount for their order. But there is an error-ish case where the promo code doesn't apply for this product. I'm unsure what response code to use.
Should this also be 200 OK (with some sort of message saying the validation of the code fails)?
Should it be 400 Bad Request?
Neither seems entirely appropriate, it's odd to say 200 OK when it wasn't "OK", however 4xx is usually for signifying a problem with the structure of the request / http protocol - and in this case the structure of the request is fine.
I'll second steveax. 422 seems like a good choice.
IMHO, you should never use 200 if the request failed.
Use an error code & if necessary, provide details in the response body:
HTTP/1.1 422 Unprocessable Entity
Content-Type: application/json
{ "reason": 1, "text": "Invalid promo code." }
On second thought, I think 403 is a good fit here:
HTTP/1.1 403 Forbidden
Content-Type: application/json
{ "reason": "bad_promo_code" }
Ultimately, it doesn't matter as long as it's documented.
I will suggest 409:
10.4.10 409 Conflict
The request could not be completed due to a conflict with the current
state of the resource. This code is only allowed in situations where
it is expected that the user might be able to resolve the conflict and
resubmit the request.