The Speed Data Rest API Specification lists the Response status as:
Possible values for status are:
• Pending
• In Progress
• Completed Successfully
• Completed With Error
• Rejected
The statusCode from the response returns a System.Net.HttpStatusCode, which doesn't include any of the above.
Similarly, the Response.ResponseStatus returns an IRestResponse.ResponseStatus which doesn't return any of the above either.
The only other status item returned is the string, Response.StatusDescription. Is that what is set to Pending, In Progress etc?
Thanks,
John
Oops, dumb question.
The items I was trying to match to the request status are the response status values. The request status is different and returns:
400 Bad Request
401 Unauthorized
403 Forbidden
413 Payload Too Large
The first three of these are in the System.Net.HttpStatusCode.StatusCode returned by the request.
Related
What response status codes should I return from an HTTP DELETE endpoint in cases:
when the resource is present (I believe, it's 200)
when the resource is absent (should it be 200 or 404, or smth?)
In other words, should I treat an attempt to delete absent resource as an error, or should I respond with OK instead?
Ok, there’s always an answer in the RFCs:
A successful response SHOULD be 200 (OK) if the response includes an entity describing the status, 202 (Accepted) if the action has not yet been enacted, or 204 (No Content) if the action has been enacted but the response does not include an entity.
Good morning:
I have a resource from my api that updates a record of my database if a condition is met, when it is met and the record is updated I return a HTTP status code 200, but I do not know what Http status code return when the condition is not met, since it can not be a 400 error, because the request is well formed
Thank you very much for the reply
You can use a 4xx even if the request is well-formed (what makes you think otherwise?):
The 4xx (Client Error) class of status code indicates that the client
seems to have erred. Except when responding to a HEAD request, the
server SHOULD send a representation containing an explanation of the
error situation, and whether it is a temporary or permanent condition.
These status codes are applicable to any request method. User agents
SHOULD display any included representation to the user.
(see https://greenbytes.de/tech/webdav/rfc7231.html#status.4xx)
Returning a 2xx when the request failed doesn't make any sense at all.
What HTTP response code should be returned when a POST request was not successful and a request body was correctly formatted?
For successful POST request i am using 201 - Created, but there is no equivalent not created code.
I am thinking either 400 - bad request but that would actually point user that a request is poorly formatted or 304 - not modified.
What HTTP response code should be returned when a POST request was not successful and a request body was correctly formatted?
If you mean the syntax of the request payload is valid but it cannot be processed due to invalid data, you can use 422:
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.
Remember to provide a good description in the response payload explaining what's wrong with the payload. Refer to the RFC 7807 for details on how to report problems in HTTP APIs.
Updates (according to the comments)
The reason why a POST request would fail is more of a business logic error, for example "account balance too low to withdraw 5.00 USD".
For the situation described in your comment, 403 or 409 would be a better fit.
6.5.3. 403 Forbidden
The 403 (Forbidden) status code indicates that the server understood
the request but refuses to authorize it. A server that wishes to
make public why the request has been forbidden can describe that
reason in the response payload (if any). [...]
6.5.8. 409 Conflict
The 409 (Conflict) status code indicates that the request could not
be completed due to a conflict with the current state of the target
resource. This code is used in situations where the user might be
able to resolve the conflict and resubmit the request. The server
SHOULD generate a payload that includes enough information for a user
to recognize the source of the conflict. [...]
I am building an API and I am returning this kind of status codes for each method (e.g., "register_user"):
200 (OK) when the user has been registered successfully
403 (forbidden) when there are missing parameters in the request
409 (conflict) when a user was already registered
In addition to the status code, I return a "message" field explaining what happened. Do you consider returning these codes in this example a good practice? Or should I return 200 in all of them but an error in the "message" field?
The 403 (Forbidden) status code indicates that the server understood
the request but refuses to authorize it. A server that wishes to
make public why the request has been forbidden can describe that
reason in the response payload (if any).
-- RFC 7231, 6.5.3
That doesn't sound like what you've got at all. The other two are reasonable. Missing parameters are typically handled with a 400 response code.
I have an api endpoint that returns a Voucher object.
The voucher is retrieved from a third party.
There are some conditions, for example an expired date, that we check for / validate on.
So, if a client application requests /voucher/1234 voucher with id 1234 is retrieved from the third party.
If the expired date is < now, we need to return an error.
I want to return standard HTTP errors.
Which would be the most suitable?
I initially thought a 412 would be, but now I'm not sure.
HTTP 412 is used when the server doesn't meet one of the preconditions(If-Match, If-Modified-Since, etc) supplied in the request header.
The very generic way would be to return HTTP 400 + specific error message on invalid fields.
However more and more populer APIs are starting to use HTTP extensions to be more granular with the error feedback to the client. Twitter and GitHub use HTTP 422 Unprocessable Entity as defined in the WebDAV HTTP extension. HTTP 422 says that :
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.
Your server understands what the user wants to do and understands what the data contains, it just won't let you do that. So, Http 422 looks good for you.