REST and the Magic of Scalability, Idempotence, and Whatnot

From time to time, I read about the magic that is RESTful services and how they solve everything and anything, such as scalability, idempotency, simplicity, and the like. For instance, in RESTful Web Services Sam Ruby and Leonard Richardson say that "PUT and DELETE operations are idempotent. If you DELETE a resource, it's gone. If you DELETE it again, it's still gone..." (p.103) and "the safe methods, GET and HEAD, are automatically idempotent as well" (p.219).

Another example comes from Anne Thomas Manes who says:

The REST architectural style defines a number of basic rules (constraints), and if you adhere to these rules, your applications will exhibit a number of desirable characteristics, such as simplicity, scalability, performance, evolvability, visibility, portability, and reliability.

The basic rules are:

• Everything that's interesting is named via a URI and becomes an addressable resource
• Every resource exposes a uniform interface (e.g., GET, PUT, POST, DELETE)
• You interact with the resource by exchanging representations of the resource's state using the standard methods in the uniform interface

I think such claims are plainly wrong and misleading. Don't get me wrong, I like the REST approach, since it encourages better service design -- e.g. document oriented message exchange vs. the RPC-like message exchange which the so called "WS-death-*s" (or actually the tools that support them) encourages.

It also encourages the above mentioned traits -- however that's exactly the point -- REST encourages this thinking not solves scalability or other problems out of the box. You still need to design your services properly.

For instance, if you follow Anne's rules you can still end up with a service which is stateful, that performs heavy distributed transactions against multiple databases and systems -- i.e. a service that is neither simple, scalable or perfromant.

DELETE will only be idempotent if the resource is idempotent (e.g. a specific version of a resource) or the message is idempotent (e.g. requesting a deletion of a specific version) if you are deleting the "recent version" then it might have been recreated between your calls you are now deleting something completely different. heck, even a GET (read) message with a single reader can be made to be non-idempotent  if you decide to code something that alters the state of a resource significantly whenever it is read. When you have multiple readers and writers GET will not be idempotent "automatically" as two consecutive reads can give you two different representations as the resource might have changed (again unless the resources are idempotent)

REST is not different from other styles in this respect; for instance you can do object orientation in C but working in an OO language encourages object orientation (the opposite is also true; using an object-oriented language does not guarantee that you get an object-oriented design).

At the end of the day, architects should still think about the design if they want to ensure the results matches the quality attributes they want to achieve. Some environments/styles/tools will make some quality attributes more easy to achieve but nothing will solve the problems for you.

Posted by Arnon Rotem-Gal-Oz at 12:58 PM  Permalink