On REST

Tim Bray posted up a good piece called ‘REST Questions‘, and one of the commentators asked several questions I felt I should respond to. This was my response with some light editing and additional links:

Mainly because there is still a little confusion on what exactly REST is?

REST is an architectural style. I think the confusion is that people confuse ‘architectural style‘ with ‘architecture‘ and ‘protocol‘, neither of which an architectural style is.

As a technology person, I sure wish REST had some very, very distinct features.

It does, only the thing to remember is that it is neither an architecture nor a protocol, but describes a set of useful and interrelated properties an architecture or protocol fitting it would have as well as the benefits and demerits resulting.

The confusion here is that people are committing a reification fallacy: they’re taking something abstract and treating it as if it’s more concrete than it is.

Even with AJAX…

That’s apples and amoebas. AJAX is quite a concrete thing: making HTTP requests in Javascript within a browser.

Let me ask this question, is there a REST RFC?

No, but there could be, and it’d be informational.

Could one be implemented?

Based on REST, you could ‘implement’ it, after a fashion, by designing a protocol based on REST.

Let me put it this way: a protocol or architecture is a reification or ‘implementation’ of one or many architectural styles. Similarly, an application or system is a reification/implementation of one or more protocols and/or architectures.

What if a server or client library fails to implement the features properly, is it still REST?

Clients and servers don’t implement REST, they implement RESTful protocols. What they’re doing is implementing or using the protocol incorrectly by going against its grain.

Lets say I don’t get HTTP right. I don’t use PUT, I don’t use DELETE. I use a heavy RPC oriented XML messaging format in POST requests. Heavy requests. Am I building a REST application?

PUT and DELETE have nothing to do with REST. You’re confusing REST’s uniform interface constraint with how HTTP implements it. RPC as an architectural style (yep, it is: it’s initial reification from style to protocol was probably RFC1050, though I’m sure something predates that) is diametrically opposed in most regards to REST, so no, it wouldn’t be RESTful. The Flickr API is RPC, plain and simple. The same goes for the ‘RESTful’ Twitter API and the ‘RESTful’ Last.fm API, both of which are RPC and definitely not RESTful.

Can you use custom XML RPC formats with REST?

I’m not quite sure what you mean, but if you mean using XML-RPC as an object serialisation format similar to JSON, sure, but that’s as far as it goes.

If REST is essentially getting HTTP right?

Yes and no. Using HTTP in a RESTful manner is getting HTTP right, but HTTP is not REST, it’s protocol that adheres to the REST architectural style.