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
Related
do you know if there is a HTTP response code for this use case:
"The user is allowed to see a fraction of the called resource but not all of it".
It sounds like a mixture between the 200 response code (because the user is allowed to retrieve some of the resource) and the 403 response code (because the user is not allowed to see all of it).
I guess the 206 response code (Partial Content) makes sense somewhat. But according to the MDN Web Docs* this response sounds very 'technical' and not business case specific.
Thank you for your help!
*https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/206
It would still be a status 200, since they are successfully getting the data they have access to. Whether or not there's other data they don't have access to makes no difference if they're getting what they do have access to. And there's no reason to tell them they don't have access to that other data if they're not trying to access it.
206 Means you're sending the data they have access to in smaller parts.
Imagine a user endpoint. Admin would have access to all user info, whereas a regular user only to their own. So you could have a /user/ to get all and a /user/:id to get a specific user.
If a regular user accesses /user/:id where id is their own id they should get a 200. If they try to access /user/ or /user/:id where id is not their id they should get a 403 (because they're not allowed to use the former and allowed to use the latter, but not get the data for that id). If they're not logged in they should get a 401 (doesn't even matter whether or not they would have access to it if they were logged in).
Same for if you just have a /user/ endpoint, where data is returned based on e.g. their id stored in a cookie.
If data is returned: 200. If they're not allowed to use that endpoint: 403. And again, if they're not logged in: 401.
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).
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 designing a Web API to serve mobile applications and I have an action that checks if a given authorization key still is valid or not. In this request I send sensitive data (like the vendor_id of a specific device). I've also learned it's important to use POST method instead of GET in order to protect the information. However, the same action is idempotent because it just checks the validity. My question is: should I use POST or GET for this purpose?
i prefer to use POST even though this is a GET per the REST architecture; i would create a separate url: /object/get when i am using POST to do a GET-like operation to distinguish it from POST-like operations which would be POSTs to /object
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.