4 ms·

> If you try to login with an email and a password, I will return a 404 with no further explanation if the auth request fails. Auth is something different. You

by rdeboo 11y ago

> If you try to login with an email and a password, I will return a 404 with no further explanation if the auth request fails. Auth is something different. You should return a 401 with no additional information indeed. However, the point is that as an API client, you want to be able to distinguish between "this bookshelf does not contain book X" and "what are you talking about, there is no bookshelf here".

maratd 11y ago
> Auth is something different. You should return a 401 with no additional information indeed. Yup, that's better. > However, the point is that as an API client, you want to be able to distinguish between "this bookshelf does not contain book X" and "what are you talking about, there is no bookshelf here". I suppose you can return a 403 if it's something you shouldn't be accessing, but then you're bleeding information. You're letting the client know that it exists, but they don't have permission to access it. A scheme that checks for permissions first and defaults to 403 when they're insufficient regardless of the existence of the resource would work though. I guess it depends on how you implement the entire system.
tiglionabbit 11y ago
In one of my projects I started returning 409 Conflict for the former case here. Its description seems to match this use case: > 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. If you consider the "current state of the resource" to be "it doesn't exist yet, but you could create it". It seems useful to distinguish between requests that could be fulfilled if the database contained different things, and requests that couldn't.

by rdeboo 11y ago

maratd 11y ago

> Auth is something different. You should return a 401 with no additional information indeed. Yup, that's better. > However, the point is that as an API client, you want to be able to distinguish between "this bookshelf does not contain book X" and "what are you talking about, there is no bookshelf here". I suppose you can return a 403 if it's something you shouldn't be accessing, but then you're bleeding information. You're letting the client know that it exists, but they don't have permission to access it. A scheme that checks for permissions first and defaults to 403 when they're insufficient regardless of the existence of the resource would work though. I guess it depends on how you implement the entire system.

tiglionabbit 11y ago

In one of my projects I started returning 409 Conflict for the former case here. Its description seems to match this use case: > 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. If you consider the "current state of the resource" to be "it doesn't exist yet, but you could create it". It seems useful to distinguish between requests that could be fulfilled if the database contained different things, and requests that couldn't.