I have a resources with uri /api/books/122 , if this resource doesn't exist at the point where a client sends HTTP Delete for this resource, what is the appropriate response code from this action? Is it 404 Not Found?
Thanks
The response code for a delete call can be any of the following :
DELETE /api/book/122 - The server successfully processed the request, but is not returning any content
204 No Content
DELETE /api/book/122 - Resource does not exist
404 Not Found
DELETE /api/book/122 - Resource already deleted
410 Gone
DELETE /api/book/122 - Users does not have permission
403 Forbidden
DELETE /api/book/122 - Method Not Allowed
405 Method Not Allowed
DELETE /api/book/122 - Conflict (User can resolve the conflict and delete)
409 Conflict
In your case 404 is apt.
Yes, it would be 404.
In general it will be a 400 series error if the request is wrong somehow, and a 500 series error if something goes awry on the server.
I would suggest taking a look at this flow diagram. It's obviously a little bit more than you need but a great resource for future readers. Sadly there is no excerpt possible.
http-decision-diagram
Related
My team is developing a simple backend service that provides the operations ADD, GET and REMOVE a very simple item. All are triggered by an http request and they do not much besides adding, getting and removing the item from a database.
Regarding the specific scenario in which a REMOVE operation is triggered on a item that is not present in the DB (e.g. was removed before), our question is what should be the response of the service? We having been debating options like 200 + some specific message, 410 - resource gone, amongst other 2XX and 4XX possibilities, but we haven't reached a consensus.
I hope this is not Bikeshedding.
Thank you for your help.
What should be the response of the service?
It's important to highlight that status codes are meant to indicate the result of the server's attempt to understand and satisfy the client request. Having said that, 2xx status codes are unsuitable for this situation and should be avoided:
The 2xx (Successful) class of status code indicates that the client's request was successfully received, understood, and accepted.
The most suitable status code would be in the 4xx range:
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.
The 404 status code seems to be what you are looking for, as it indicates that the server can't find the requested resource:
6.5.4. 404 Not Found
The 404 (Not Found) status code indicates that the origin server did not find a current representation for the target resource or is not willing to disclose that one exists. A 404 status code does not indicate whether this lack of representation is temporary or permanent; [...]
If you are concerned on how the client will understand the 404 reponse, you could provide them with a payload stating that such resource is no longer available.
And just bear in mind that ADD and REMOVE are not standard HTTP methods. Hopefully that was a typo and you are using POST (or PUT) and DELETE to express operations over your resources.
I am in process of building a rest server, which will be called to abort a long running process by client.
/abort/{processID}
Now if process with processID is not found, I am returning 404 Not Found
However if the process has already been completed/is not running, then what shall be correct HTTP Error code for the same?
406 Not Acceptable is relevant to Accept header (and hence I think I shall not used).
400 Bad Request appears to be too generic.
Seeking suggestions on which header will be optimum for it?
Short answer
Here are some reasonable options that may suit you:
404 Not Found
410 Gone
409 Conflict
403 Forbidden
The right choice relies on the semantics of process has already been completed/is not running:
If the process no longer exists, consider 404 or 410, depending on whether the condition is permanent or not.
If a process can be found with a given id, but the attempt to abort this process cannot be completed due to a conflict with the current state of the process, you could go for 409.
If the operation is forbidden for other reasons, choose 403.
The process no longer exists
If the process no longer exists, you could choose between 404 and 410, depending on whether the condition is (or it is possible to determine whether the condition is) permanent or not.
See the following quotes from the RFC 7231:
6.5.4. 404 Not Found
The 404 (Not Found) status code indicates that the origin server
did not find a current representation for the target resource or is
not willing to disclose that one exists. A 404 status code does
not indicate whether this lack of representation is temporary or
permanent; the 410 (Gone) status code is preferred over 404 if the
origin server knows, presumably through some configurable means, that
the condition is likely to be permanent. [...]
6.5.9. 410 Gone
The 410 (Gone) status code indicates that access to the target
resource is no longer available at the origin server and that this
condition is likely to be permanent. If the origin server does not
know, or has no facility to determine, whether or not the condition
is permanent, the status code 404 (Not Found) ought to be used
instead. [...]
The process exists, but the operation causes a conflict
If the process exists, 404 or 410 are not the good choices.
If the attempt to abort an existing process cannot be completed due to a conflict with the current state of the process, you should consider 409 along with a payload that describes the reason of the conflict.
See the quote:
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. [...]
The process exists, but the operation is forbidden for some reason
One last option is 403. This status code is frequently used for authorization problems, when the credentials are valid, but they are insufficient to authorize the request.
However 403 is much broader than that and could be used to indicate that a request is forbidden for reasons unrelated to the credentials. Just be sure you provide a payload that describes why the operation is forbidden.
See the quote:
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).
If authentication credentials were provided in the request, the
server considers them insufficient to grant access. The client
SHOULD NOT automatically repeat the request with the same
credentials. The client MAY repeat the request with new or different
credentials. However, a request might be forbidden for reasons
unrelated to the credentials.
An origin server that wishes to "hide" the current existence of a
forbidden target resource MAY instead respond with a status code of
404 (Not Found).
Say I've got a resource
/Products/123
And each Product has an associated Supplier entity in the back end database. POST and PUT requests must specify a supplier ID, which is then used to fetch a Supplier entity from the database.
What should be returned if a user issues a PUT /Products/123, which is found, but includes a bad Supplier ID, which is not?
404 Not Found with a message specifying which resource wasn't found?
409 Conflict?
The 404 status code may not be right choice because the resource that has not been found is not the target of your request:
6.5.4. 404 Not Found
The 404 (Not Found) status code indicates that the origin server did
not find a current representation for the target resource or is not
willing to disclose that one exists. A 404 status code does not
indicate whether this lack of representation is temporary or
permanent; the 410 (Gone) status code is preferred over 404 if the
origin server knows, presumably through some configurable means, that
the condition is likely to be permanent.
The 409 status code might be suitable for this situation, but is not be the best choice (I wouldn't define this situation as a conflict):
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 would go for 422 status code with a clear description in the response payload:
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.
If 422 doesn't work for you, use the generic 400:
6.5.1. 400 Bad Request
The 400 (Bad Request) status code indicates that the server cannot or
will not process the request due to something that is perceived to be
a client error (e.g., malformed request syntax, invalid request
message framing, or deceptive request routing).
The following diagram (extracted from this page) is pretty insightful when it comes to picking the most suitable 4xx status code:
I don't believe that there is a correct answer for this question (unless some REST purist can shed some light) but we currently use (or abuse...) HTTP 400 (Bad Request) with an additional HTTP Header explaining the error (i.e. X-Error: Invalid supplier ID). However a HTTP 422 would also be a good alternative.
Statuses 404 or 409 would be confusing since there is no clear way to specify that the response is about a sub-resource.
Hello I would use the 404 as mentioned prior:
6.5.4. 404 Not Found
The 404 (Not Found) status code indicates that the origin server did
not find a current representation for the target resource or is not
willing to disclose that one exists. A 404 status code does not
indicate whether this lack of representation is temporary or
permanent; the 410 (Gone) status code is preferred over 404 if the
origin server knows, presumably through some configurable means, that
the condition is likely to be permanent.
Because the product that you are looking for exists, but the Supplier ID not, so basically is like we are looking for you in a different city, you exist but not in that city, so we will say, hey we did not found you.
I believe that supplier and product they have a relationship and it is a hard relationship, that a product can not exist if you don't have a supplier for that product, so that means you can not update a product if you don't know it is supplier.
Scenario:
A POST request is sent to process an order that will result in data retrieval from an external datasource.
There are three possible results:
The datasource returned data for the request
No data was available for the request (this is viewed as an error)
The datasource couldn't be accessed (may be down for maintenance)
An obvious response for 1 is 200: OK or 201: Created (an entity is created from this request).
What status codes would be appropriate for 2 and 3?
Status codes I have considered:
503: Service Unavailable when datasource is down
500: Internal Server Error when datasource is down
502: Bad Gateway when "no data available"
404: Not Found when "no data available"
403: Forbidden when "no data available"
412: Precondition Failed when "no data available"
2) Looking back at this, I agree it should probably be either a 204 No Content or maybe a 200 with a body indicating no records or resources could be found depending on the structure returned.
404's are generally used when the resource URI doesn't exist or a resource in the URI is not found in the case of a restful service.
3) 503 Service Unavailable
The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition which will be alleviated after some delay. If known, the length of the delay MAY be indicated in a Retry-After header. If no Retry-After is given, the client SHOULD handle the response as it would for a 500 response.
Note: The existence of the 503 status code does not imply that a
server must use it when becoming overloaded. Some servers may wish
to simply refuse the connection.
3) I agree with 503 for this
2) Frankly I think a good argument could be made for using 204 in case 2 You can include metainfo in the header to indicate specifically what 'went wrong'. It really depends on how much you consider this case to be 'an error' at the API level.
If the API itself is functioning as intended, and the request was to a valid endpoint, by an authenticated and authorized user and did not cause the server to malfunction, then very few of the 400 or 500 series errors would really seem to apply.
for example, 404 usually means the URI you called does not exist, if it does exist, then using that code is misleading at least IMHO
**10.2.5 204 No Content**
The server has fulfilled the request but does not need to return an
entity-body, and might want to return updated metainformation. The
response MAY include new or updated metainformation in the form of
entity-headers, which if present SHOULD be associated with the
requested variant.
If the client is a user agent, it SHOULD NOT change its document view
from that which caused the request to be sent. This response is
primarily intended to allow input for actions to take place without
causing a change to the user agent's active document view, although
any new or updated metainformation SHOULD be applied to the document
currently in the user agent's active view.
The 204 response MUST NOT include a message-body, and thus is always
terminated by the first empty line after the header fields.
HTTP 404 - With your own error message like "No data found".
Twitter uses 404.
Reference: https://developer.twitter.com/en/docs/basics/response-codes.html
The datasource returned data for the request
200: OK/201: CREATED
Because everything is working as expected
No data was available for the request (this is viewed as an error)
400: BAD REQUEST
The request was invalid or cannot be otherwise served. An accompanying error message will explain further inside the body.like:
HTTP 400
{
response: null,
code: "USER_101", //should be used customized error codes here
error: "User details not found"
}
The datasource couldn't be accessed (may be down for maintenance)
404: Resource/URI NOT FOUND
The URI requested or resource is invalid
Like: https://www.lipsum.com/list-page
**/list-page** is not defined/found
Find here most frequently used status codes:
200 – OK
Everything is working, The resource has been fetched and is transmitted in the message body.
201 – CREATED
A new resource has been created
204 – NO CONTENT
The resource was successfully deleted, no response body
304 – NOT MODIFIED
This is used for caching purposes. It tells the client that the response has not been modified, so the client can continue to use the same cached version of the response.
400 – BAD REQUEST
The request was invalid or cannot be served. The exact error should be explained in the error payload.
401 – UNAUTHORIZED
The request requires user authentication.
403 – FORBIDDEN
The server understood the request but is refusing it or the access is not allowed.
404 – NOT FOUND
There is no resource behind the URI.
500 – INTERNAL SERVER ERROR API
If an error occurs in the global catch blog, the stack trace should be logged and not returned as a response.
In my opinion the best way to handle this is with a 200 no result object.
Why?
You have a response that you can do something with without a lot of trouble. I searched, everything worked correctly but there wasn't anything in the database to give a result. Therefore, result = null and a message explaining as much. If something found this in the network calls it is not a security risk.
If you are concerned with a security risk then a 204 is probably the best approach.
res.status(200).send({
result: null,
message: 'No result'
});
In my RESTful API client might try to post information that is already in the database, this is not an error, rather something client can ignore, maybe notify the user about already existing dublicate.
Now i'm returning 409 Conflict and already existing object in the response body. I feel that it's incorrect because:
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. The response body SHOULD include enough
information for the user to recognize the source of the conflict.
Ideally, the response entity would include enough information for the
user or user agent to fix the problem; however, that might not be
possible and is not required.
via restpatterns.org
and in general, it seems, that 409 is more associated with PUT.
What is the correct response in this case? Could it be 303 See Other and Location header?
I'm not sure there is a correct answer. We are returning a 409 with a message that it's a duplicate resource. We also include hypermedia to that resource. It seems you could also use a 400 - Bad Request but that seemed too generic. I could see the 303 also working. I wanted to indicate that there was an error so we went with the 409.