Mixture between 200 (OK) and 403 (Forbidden) HTTP response - api

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.

Related

Is there a status code to use when the response from server is missing a required field?

Say I make an API call to the server to get all information for a specific user, e.g. first name, last name, age, to display on the UI. However, when the response from server comes back, there is only last name and age available. Is there an appropriate error code to use for this missing data error? I was thinking it would be a generic 500 error since the response is incorrect. However, from the server side, there was no real error since its just a get call to the database. Is there a more appropriate error code to use for this case?
From what I understand,
API User asks for User n°XXXX and the server can't return every "required" information. It looks like a 200, the server understood the request so far and did return what the database contains. It is api user's job to check that returned data does contain every required fields.
However, if api user doesn't provide enough informations to retrieve user then it's a 4xx as the request is malformed and the server will not be able to retrieve data.

Standard Response of a Login/Sign In API

While making an Login/SignUp RESTful API, should the response contain any other user information e.g. User Profile, Permissions etc?
When I've done this previously the Login returns a token for the new session and possibly the userid. Then I've had other services that I call with this token to get a list of permissions etc. You should make each resource do a single thing, which allows greater flexibility and reuse. Like everything though... this is my opinion on it but there is no right or wrong way to do it.
The REST principle is that when you POST a request to the server, it should respond with a status to indicate success or failure (i.e. 201 created) and a pointer to the new resource just created.
In my comments above the resource being created is the session and the token is the identifier of that resource.

How to check if entity is inside a list with RESTful APIs?

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

Appropriate HTTP status code for case when only one submission per user is allowed

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.

REST API code/message for missing parent resource

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.