Why is Bad REST Easy?

In my view, the answer is simple. We have long been following action-oriented principles to designing distributed software, and action-oriented interfaces, when translated into REST, simply put, suck.

In response to my post on A RESTful version of Amazon’s SimpleDB, someone made this comment:

I don’t know why so many people seem to have a hard time with RESTy design.

Here is my response.

Taking the case of the SimpleDB API, a simplified remote interface in a programming language such as Java would have looked like this:

interface SimpleDB {
void createDomain(String domainName);
void deleteDomain(String domainName);
List<String> listDomains(int max);
void putAttributes(String domainName, String itemName, List<Attribute> attributes);
void deleteAttributes(String domainName, String itemName, List<String> attributes);
List<Attribute> getAttributes(String domainName, String itemName);
}

Such an interface would map naturally to a distributed object model like an EJB, and of course, to a WSDL as well. Right now, I am unable to access the SimpleDB WSDL, but I am sure it will map to such a Java interface very well.

Let us take another example. Over the last 5-6 years, what was the most predominant architecture pattern among enterprise and web developers? It is the Model View Controller pattern. If we translate the SimpleDB interface interface into an MVC web-framework like Struts, it would include the following actions:

• createDomain
• deleteDomain
• listDomains
• putAttributes
• deleteAttributes
• getAttributes

This style is natural for an MVC web framework to specify actions that a user-agent would submit.

Both these examples illustrate an action-oriented approach towards designing remote interfaces. In an action-oriented approach, the primary conversation-point between clients and servers is what do you want to do, i.e., an action. The data data to make an action happen gets supplied as an argument with each request.

Let me be clear that, in both these examples the action-oriented approach may be natural for the respective problems. But this philosophy does not translate into resource-oriented interfaces. That is where the trouble lies.