StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

POWhat's the RESTful way to check whether the client can access a resource?
text
Body
copied!<p>I'm trying to determine the best practice in a REST API for determining whether the client can access a particular resource. Two quick example scenarios:</p> <p>A phone directory lookup service. Client looks up a phone number by accessing eg.<br> <code>GET http://host/directoryEntries/numbers/12345</code><br> ... where <code>12345</code> is the phone number to try and find in the directory. If it exists, it would return information like the name and address of the person whose phone number it is.</p> <p>A video format shifting service. Client submits a video in one format to eg.<br> <code>POST http://host/videos/</code><br> ... and receives a 'video GUID' which has been generated by the server for this video. Client then checks eg.<br> <code>GET http://host/videos/[GUID]/flv</code><br> ... to get the video, converted into the FLV format, if the converted version exists.</p> <p>You'll notice that in both cases above, I didn't mention what should happen if the resource being checked for <em>doesn't</em> exist. That's my question here. I've read in <a href="https://stackoverflow.com/questions/1533510/rest-standard-for-get-on-a-resource-that-doesnt-exist">various</a> <a href="http://watchitlater.com/blog/2009/11/http-method-primer-for-restful-web-services/" rel="nofollow noreferrer">other</a> <a href="https://stackoverflow.com/questions/9431922/rest-standard-for-checking-if-resource-exists">places</a> that the proper RESTful way for the client to check whether the resource exists here is to call <code>HEAD</code> (or maybe <code>GET</code>) on the resource, and if the resource doesn't exist, it should expect a 404 response. This would be fine, except that a 404 response is widely considered an 'error'; the <a href="http://tools.ietf.org/html/rfc2616" rel="nofollow noreferrer">HTTP/1.1 spec</a> states that the 4xx class of status code is intended for cases in which the client 'seems to have erred'. But wait; in these examples, the client has surely not erred. It <em>expects</em> that it may get back a 404 (or others; maybe a 403 if it's not authorized to access this resource), and it has made no mistake whatsoever in requesting the resource. The 404 isn't intended to indicate an 'error condition', it is merely information - 'this does not exist'.</p> <p>And browsers behave, as the HTTP spec suggests, as if the 404 response is a genuine error. Both Google Chrome and Firebug's console spew out a big red "404 Not Found" error message into the Javascript console each time a 404 is received by an XHR request, regardless of whether it was handled by an error handler or not, and there is no way to disable it. This isn't a problem for the user, as they don't see the console, but as a developer I don't want to see a bunch of 404 (or 403, etc.) errors in my JS console when I know perfectly well that they aren't errors, but information being handled by my Javascript code. It's line noise. In the second example I gave, it's line noise to the extreme, because the client is likely to be polling the server for that <code>/flv</code> as it may take a while to compile and the client wants to display 'not compiled yet' until it gets a non-404. There may be a 404 error appearing in the JS console every second or two.</p> <p>So, is this the best or most proper way we have with REST to check for the existence of a resource? How do we get around the line noise in the JS console? It may well be suggested that, in my second example, a different URI could be queried to check the <em>status</em> of the compilation, like:<br> <code>GET http://host/videos/[GUID]/compileStatus</code><br> ... however, this seems to violate the REST principle a little, to me; you're not using HTTP to its full and paying attention to the HTTP headers, but instead creating your own protocol whereby you return information in the body telling you what you want to know instead, and always return an HTTP 200 to shut the browser up. This was a major criticism of SOAP - it tries to 'get around' HTTP rather than use it to its full. By this principle, why does one ever need to return a 404 status code? You could always return a 200 - of course, the 200 is indicating that the a resource's <em>status information</em> is available, and the status information tells you what you really wanted to know - the resource was not found. Surely the RESTful way should be to return a 404 status code.</p> <p>This mechanism seems even more contrived if we apply it to the first of my above examples; the client would perhaps query:<br> <code>GET http://host/directoryEntries/numberStatuses/12345</code><br> ... and of course receive a 200; the number <code>12345</code>'s <em>status information</em> exists, and tells you... that the number is not found in the directory. This would mean that ANY number queried would be '200 OK', even though it may not exist - does this seem like a good REST interface?</p> <p>Am I missing something? Is there a better way to determine whether a resource exists RESTfully, or should HTTP perhaps be updated to indicate that non-2xx status codes should not necessarily be considered 'errors', and are just information? Should browsers be able to be configured so that they don't always output non-2xx status responses as 'errors' in the JS console?</p> <p>PS. If you read this far, thanks. ;-)</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload