An Architect's View

5 responses so far ↓

• 1 Mark // May 7, 2007 at 5:04 PM

  Hi Sean
  
  Very interesting presso! However I've got one gripe with it....
  
  In your discussion of REST services you seem to be discouraging HTTP status codes in favour of using custom XML to reveal that an error has occurred and bypasses one of the most useful features of HTTP.
  
  Maybe I'm missing something here, but to my way of thinking this breaks the whole REST model.
  
  Your example on page 25 is fine long as it is accompanied by a 40X HTTP response code, but sending it back with a status 200 just seems wrong. It's like using the POST method for a search form... you loose one of the great benefits of REST/HTTP.
  
  What is confusing me more is that your justification for this seems to be that these statuses make no sense to clients of your services. What sort of rest client doesn't understand a 100, 401 or 500 HTTP status? The only one I can think of is IE6 with the "Friendly HTTP Errors" option turned on.
  
  We have recently finished a big application and have worked hard to correctly implement HTTP status codes in the web interface. We find these *are* well understood by clients and they really help our testing. For example we can run a spider over the system or feed a bunch of constructed URLs to a generic HTTP bot and easily check that our app is returning 500s, 404s, 401s and 200s where expected. Kind of like unit testing, but at the HTTP level.
  
  We could make a bot that acuatlly knows how to parse and understand custom errors - but why do this when HTTP statuses work so well?
  
  Anyway - let me know I've just missed your point.
  
  
  Cheers
  
  Mark

• 2 Sean Corfield // May 7, 2007 at 6:53 PM

  @Mark, yes, I understand why the REST crowd use HTTP status codes and to return *specific* code and *specific* message values (e.g., like the type mnemonic I show). My main point - which you did miss - was that you can't throw exceptions because that just gives an uninformative 500 error. Furthermore, HTTP status codes generally have fixed meanings that don't always correspond to what information you need to return.
  
  Purists in the REST world seem to like using PUT and DELETE HTTP operations but in real world systems, people stick to POST and GET. Yes, you could return status 404 from a GET for an object that doesn't exist but that's overloading the 404 - "I couldn't find that URL" - that normal HTTP operations provide.
  
  I don't like that overloading so I stand by my recommendation to return custom, informative data packets.

• 3 Mark // May 7, 2007 at 7:27 PM

  Hi Sean
  
  But what about "custom, informative data packets" along with the right HTTP status code? 500s don't have to be uninformative. CF error pages are the perfect example - lots of custom detail & debugging info along with a 500 HTTP status.
  
  
  Mark

• 4 Sean Corfield // May 7, 2007 at 7:49 PM

  @Mark, I still say this is the wrong approach: after all, the request to the server *succeeded* and returned a valid packet (albeit one that describes a method call failure).
  
  For example, returning a 401 error for an authentication failure - the RFC requires that a WWW-Authenticate header must be returned, but that's not appropriate for an authenticate() method call where you supply the wrong username / password.
  
  500 means "The server encountered an unexpected condition which prevented it from fulfilling the request." but that is *not* the case for errors returned from services - those are, by definition, *expected* conditions.
  
  Look at the status definitions:
  
  http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
  
  Bending those to fit an application model seems very suspect to me... Returning 200, 201 and 202 in some circumstances seems OK I guess. Maybe even 203. The others just don't seem to fit.
  
  If you think you really do have a good fit, I'd be interested to see a full blog post explaining what you did and how it conforms the HTTP status code protocol.

• 5 Tom Chiverton // May 9, 2007 at 2:40 AM

  Very, very interesting - and I'm also glad we're using some of the same ideas (like returning a success/failure Boolean, along with the data) in our own methodology (http://rachaelandtom.info/building-coldfusion-services-0)

Leave a Comment