0

To simplify, say you have a REST API with a frontend that has login form in the frontend and you want to check whether a User exists or not. Front-end HTTP/POST some data to the back-end and back-end queries the database. The result is the user does not exist and you want to return that result to the front-end.

I know there might be tons of ways to return the result, but is there any "standard" or "more correct way" to return "User does not exist" result as JSON? Some posibilities i'm thinking:

  1. Return a JSON as a string with the result?
  2. Return empty object?
  3. Return empty User object with a boolean doesNotExist=false?
  4. Return 404 not found or some other http code response?
  5. A mix between 4 and 1?

Solution:

Responding with a HTTP 404 Code is enough, no JSON body is needed. Keep in mind for this login use case, as pointed out by the answers, it is not recommended to repond with a 404 HTTP when the user is not found for security purposes.

Useful resource:

Understanding REST: Verbs, error codes, and authentication

AkuLink1
  • 123
  • 10
  • *"...but is there any "standard" or "more correct way" to return "User does not exist" result as JSON..."* No, there isn't. There are arguments for various alternatives, primarily opinionated ones. Primarily the argument is between 404 and 200-with-status-flag. It hinges on what you consider the resource to be (the retrieval endpoint, or the user being retrieved), which brings us back to opinion. :-D – T.J. Crowder Mar 09 '21 at 18:21

2 Answers2

0

The standard way to handle the situation where you don't find a resource is to return a 404 error status. If, for example, your uri is something like /user/{id} then this is an attempt to access a resource/document of type user with the given id, and in this case, if the user is not found then a 404 would be entirely appropriate. You do not need to specifically return a json response in this case.

However, you should be aware that for security purposes it is considered insecure to validate the existence of a user in this way. If an attacker knows a valid username or id they can try to brute-force their password. A lot of systems return the same error for invalid user identifiers and invalid password -- invalid credentials -- so that attackers cannot know if they have guessed the username correctly. A 401 error is often considered a useful response when attempting to authenticate a user. If the user does not exist or the given creds are invalid, then a 401 should be returned.

Software Engineer
  • 15,457
  • 7
  • 74
  • 102
  • Oh ye, thanks for pointing out. So I understand for this login use case specifically you do not need a JSON response, you always return the same status whether user exists or password is incorrect for security purposes. But leaving good practices aside and saying its just a random form where you want to display a different message depending on what you found on database ("Not found", "Found but this field does not exist", "Wrong information"...) You handle this in the front-end entirely using HTTP responses? You always return the same http code + a message? Where do you place that message? – AkuLink1 Mar 10 '21 at 09:18
  • The code is sufficient. In my example URL you would respond 404 if {id} doesn't exist. Error messages are not recommended. The UI should decide how to represent this to the user, not the API. – Software Engineer Mar 10 '21 at 12:06
  • Adding content to an error status is often reserved for 500+, and only in debug mode, where you're trying to communicate the error details to a developer. – Software Engineer Mar 10 '21 at 12:09
  • Okay tyvm, this has been enlightening. So I guess for the UI to handle the response you can you provide something like a unique error code for your application that the UI can interpret. Say for example Http Body: "status":404", "error": "error-0001" being error-0001 unique to your application? Or is there a better way to do that? – AkuLink1 Mar 10 '21 at 16:02
  • Not exactly. For expected status' like 404 you don't need a body - it's redundant. The status code is sufficient info all by itself. You'd only add a body when there is a real need for something extra, such as a stack trace in the case of a 500 - server error. – Software Engineer Mar 10 '21 at 16:07
  • You'll find that in your js code you'll end up ignoring the body for 404's and the like, and if your API is public nobody will expect there to be a body so it'll get ignored by everyone else anyway – Software Engineer Mar 10 '21 at 16:09
  • OP - Not that this is a REST standard/convention, and is not inherent to HTTP. – ryanwebjackson May 06 '21 at 16:01
-2

There is some standard way, most of the time HTTP status code is sufficient. In case you think of a custom message with more detail then make a POJO containing error code, detail, or even an exception category and return it to UI.

Niraj Jha
  • 455
  • 3
  • 10