We need to implement account deletion. One of the endpoints should send a letter to user's email address to confirm deletion. I am thinking of something like
POST /users/me/requests/deletion
However, there is a posibillity that user does not have a confirmed email address. In this case he cannot delete his account. Which is the best status code to return in this situation? We cannot decide between 409 Conflict, 403 Forbidden and 422 Unprocessable Entity.
Personally I'd go for 409 Conflict with a proper message describing the problem. This is the most general error status code and be definitely used here.
403 Forbidden most often indicates a problem with authentication but this is not always the case. It can be used to forbid access even if there's no issue with credentials. So it can be used here however it my personal opinion it doesn't suit well. Documentation says that that 403 Forbidden indicates that the server just refuses to fulfill the request and nothing can help - so it may be a good choice here as well.
422 Unprocessable entity indicates problems with the entity being sent or processed. Here the entity isn't clearly visible. This error mostly indicates problems with the request itself (misused 400 Bad Request) or with entity validation that can't be processed at the earlier stages of processing (e.g. DB constraint violation).
Related
I am designing the APIs for the backend of my app.
Suppose the user can follow the activity of another user.
In this case, I designed an API which allow me to do:
POST /me/following
and the id as body for this request.
Then I can retrieve the list of followers in this way:
GET /me/following
This API comes with pagination, so I cannot retrieve the entire list at once.
But how can I check if the user follows another user? Should I use something like
GET /me/following/{user_id}
and check the status code for this request? Like 200 it exists or 404 it doesn't exists in the list?
Usually 404 means the endpoint called doesn't exists. What if the entity doesn't exists? Is there a status code for that?
GET /me/following/{user_id} seems good.
I would probably return a 204 No Content :
Successful 2xx
This class of status code indicates that the client's request was successfully received, understood, and accepted.
[...]
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.
404 in contrast describes some kind of error, though it could do the job as well depending how you look at it
Client Error 4xx
The 4xx class of status code is intended for cases in which the client
seems to have erred.
404 Not Found
The server has not found anything matching the Request-URI. No
indication is given of whether the condition is temporary or
permanent.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
I'm designing an endpoint for my API where only one submission is allowed per user. After reading the specification and trying to find the best response, I am hesitantly planning on using a 403 - Forbidden when the user attempts to submit a second one:
10.4.4 403 Forbidden
The server understood the request, but is refusing to fulfill it.
Authorization will not help and the request SHOULD NOT be repeated. If
the request method was not HEAD and the server wishes to make public
why the request has not been fulfilled, it SHOULD describe the reason
for the refusal in the entity. If the server does not wish to make
this information available to the client, the status code 404 (Not
Found) can be used instead.
I was always under the impression though that 403s where meant to be an access response - not necessarily something that responds to state issues. Is this correct? Or is there a better status code I should be using here?
I've always 403 with authorization/authentication issues so I'm puzzled a bit ;) Below is the list of codes I'd take into consideration:
403 Forbidden - (as mentioned above)
409 Conflict - since a resource is in a given state that can't be changed it also a good status to notify the user about the problems.
And just a curiosity:
410 Gone - request can be sent exactly once so the endpoint may be not available for subsequent requests. I do not consider it as good idea, since the endpoint is still available but will not be processing request from particular user. Hmm.. Might be considered weird.
I'd vouch for 403 or 409 and eventually will use rather 409. 429 seems not to be a good idea because it's rather associated with network (broadband, throughput) problems rather than with resource itself.
I'm looking for some guidance for the correct response code & message when requesting for a resource that forms part of another resource.
For example, a GET request on:
users/{id}
where the user does not exist would return a 404, with a message of user resource not found.
My question is, what should the following return when no user resource is found:
users/{id}/friends
I'm currently returning the same code/message as in the first example. Should I be returning a message relating specifically to the friends resource? I personally think it's more helpful to make the API client aware that the parent resource isn't found, incase you have a larger URI chain.
In this particular example, if the point is to let the client differentiate between a friends request for a non-existent user, and a friends request for a user who simply has no friends, I think it would make the most sense to return 404 in the first case, and 200 with an empty set in the second.
In other words, "none" is a valid value for friends. There's no case where a user exists but their (potentially empty) list of friends doesn't, so there's never any ambiguity in issuing a 404 for the parent resource.
I’d be tempted to return a 400 Bad Request header, and place the error message in the body of the response. Unfortunately there’s no right or wrong answer in this scenario, so go with what works best for you and your application.
So say I find that I'm getting requests to my web application that are obviously SQL injection attacks or similar. I write a short test to check request variables for "naughty" strings. If I find one, what code ought I to respond with?
I'm thinking of returning "403 Forbidden" and no content, but I'm not sure.
I would think 403 Forbidden means that the resource shouldn't be accessed.
I'd thus use 400 Bad Request instead. After all, the user is allowed to the page so long as they're making a legitimate request.
http://en.wikipedia.org/wiki/List_of_HTTP_status_codes
To me the '400: Bad request' seems the most logical option.
Edit:
Maybe it depends more on the context.
If it's really impossible to continue your script, return the 400 or 404 code.
In all other situations, the user (hacker) shouldn't be notified when your code 'detects' a malicious attempt. Your validation should be of the kind that detects invalid input, not malicious attempts.
The only exception are brute-force attacks (more information on how to prevent those at Preventing Brute Force Logins on Websites ).
E.g.:
If your form contains a text box for username and the user (hacker) tries to login/register with some sort of quoted SQL statement, your validation should automatically state 'Invalid username'.
On the other hand, for login purposes, you should secure your application against brute-force attacks with the options stated in the link.
If you're able to identify the problems with the requests and they are asking for something allowed, just in a sneaky way, you should be able to prevent any damage from them and just handle them. But if the requests make no sense, 400 Bad Request is probably the best choice.
I agree with the premise of the question that there should be an HTTP code for malicious request. Informing the hacker that this is a malicious request is not a problem because they already know it is malicious. And the fact that they now know that the server knows could be a deterrent. In any case, it wouldn't give the attacker any advantage. However, the big advantage of such a code is that any service provider handling that request would now know this was a malicious request and could then take specific actions. For example, a company like CloudFlair could use this to automatically ban IP addresses from which such malicious requests emanate.
I'm designing a RESTful API and systems using the API do work on behalf of a user.
We use a standard OAuth exchange to verify that user, but upon verification we may find that the user requires to accept an updated user agreement before any other methods can be allowed. Think of the iPhone and how they change their agreements and require users to accept.
What status code would best represent this situation? Should they be given a 401 with additional information. A redirect? A custom code in the 400 range?
Obviously I don't want the API consumer to think he has a valid token, but they need to know that specific actions should be taken.
Has anyone handled something like this?
403 Forbidden
With additional information about the reason of course. This will show that you have understood the request, and you can state your reasons for refusing to comply.