Sorry, but the "AJAX Integration with Scorpio" talk will not be posted. It's all about prerelease features and those are subject to change per the usual disclaimer that Ben, Jason and Adam all put in their slide decks. I expect I'll be revising it for CFUNITED anyway and, once Scorpio is released, I'll make sure it is fully up-to-date and post it then, with code.
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
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.
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
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.
