13

The resource /user/12345 doesn't exist. Lets say the consumer is trying different ids randomly. There is no authorization. Any user can view any user. In a broader sense, my question is "What should you return if you do a GET on a resource that doesn't exist?"

Should I return an empty user for an id that doesn't exist or should I return an error message with proper status code?

What is the typical/usual/recommended practice?

Langali
  • 3,189
  • 7
  • 38
  • 45
  • 1
    REST isn't standardized. HTTP (on which REST depends) is standardized. Do you mean "Typical" or "Usual" or "Recommended"? – S.Lott Oct 07 '09 at 19:13
  • May I say I want know all of the arguments? – Langali Oct 07 '09 at 19:17
  • 1
    @Erlanged: Please update your question with additional information. There's no "standard", so it would help to clarify your question. Please do not add comments. Please *update* the question and the title to reflect what you want to know. – S.Lott Oct 07 '09 at 19:25

9 Answers9

26

Return 404 status code.

Byron Whitlock
  • 52,691
  • 28
  • 123
  • 168
16

It depends on your security concerns a little bit. I would either send a 404 if it is OK that the guesser finds out if that user id does not exist, or send 401 for all attempts on unauthenticated accesses to any resource under /user

stinkymatt
  • 1,658
  • 11
  • 14
  • 4
    Decide on either 401 or 404 and stick with it for all IDs, whether they exist or not. You don't want a hacker finding out which IDs are worth something by analysing which ones returned which error code. – Christian Hayter Oct 07 '09 at 19:11
  • @Christian Hayter: See @eglasius' note on checking authorization, first, to determine whether 401 or 404 is in order. – user359996 Mar 06 '11 at 04:39
6

404

That said, this assumes you first checked authorization to that operation -> /user/[id] and if the user wasn't allow to access Other users accounts you would return 401.

Never rely on the user not knowing user ids ...

eglasius
  • 35,831
  • 5
  • 65
  • 110
5

@Byron is right, return HTTP 404. You want to leverage all of the capabilities of HTTP, and these include response status codes. So if there is a client error, return a 4xx error code, and if your server code has an internal problem, return a 5xx error code, etc.

Richardson and Ruby's RESTful Web Services (O'Reilly) has a good discussion of this, and an appendix with all the most important HTTP error codes and when to use them.

Jim Ferrans
  • 30,582
  • 12
  • 56
  • 83
2

If the user is authenticated and authorized, return 404. If the user is unauthenticated and unauthorized, send them to a page to get authorized.

MatthewMartin
  • 32,326
  • 33
  • 105
  • 164
1

A GET should only retrieve something that exists.

So I would return a 404.

DJ.
  • 16,045
  • 3
  • 42
  • 46
1

That looks like a 404 error to me - resource not found.

Nathan
  • 2,053
  • 1
  • 14
  • 18
0

My opinion: Return an empty 200.

Quite frankly, if a REST resource doesn't exist, it doesn't exist. That means return 404. In your case, however, 12345 is a parameter you are using to identify/lookup a return entity. Resource /user/{userId} does actually exist, so technically I don't believe it is proper to return a 404, although it's clear to see the argument for either side.

If you feel like returning two status codes exposes your system in some way, however, I'd say stick with an empty 200 OK.

tehemperorer
  • 259
  • 3
  • 5
0

From your original question, with no authorization, this is clearly a 404. If you were to add authorization, then it would actually be acceptable to return a 404 for all unauthorized requests; this prevents random ID guessing by distinguishing 401 or 403 (exists, but unauthorized) from 404s (nonexistent) as some of the other answers suggest. Per the RFC:

10.4.5 404 Not Found ... This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable.

Jon Moore
  • 1,370
  • 10
  • 11