A recent blog on EBPML.ORG entitled “REST 2010 - Where are We?” very aggressively stated: “REST is just a "NO WS-*" movement.” The arguments presented are definitely interesting but the most compelling point made is in the way that REST APIs are constructed, namely that unlike the “ideal” REST API described where HTTP methods are used to define action (verb) and the path the resource (noun), practical implementations of REST are using a strange combination of both actions (verbs) and resources (nouns) in URIs.

What this does is simulate very closely SOA services, in which the endpoint is a service (resource) upon which an action (method) is invoked. In the case of SOAP the action is declared either in the HTTP header (old skool SOAPaction) or as part of the SOAP payload. So the argument that most REST APIs, in practice, are really little more than a NO WS-* API is fairly accurate.

In “REST != HTTP “ Ted Neward very convincingly argues that the problem isn’t that most “REST” APIs aren’t REST (based on the definition and constraints set down by Fielding in the first place) but that folks are calling them REST despite the fact that they aren’t. That’s not necessarily the developer’s fault and, in the cases pointed out it’s quite possible that the decision to call the API a RESTful API was made by someone other than the developer.

The fact is that there are artificial environmental constraints that force RESTful developers into diverging from the “one true REST path” that leads to a more services-based and less structured implementation than perhaps many would like.

Here’s a few of the problems developers face:

• HTML (version 4 and lower) and XHTML 1 only support GET and POST in FORMS
  
• XHTML 2.0 will support GET, POST, PUT and DELETE  in FORMS but will almost certainly be incompatible with previous versions of HTML/XHTML
  
• HTML5 appears to support all necessary HTTP methods, but is being held up by conflicts internal to the W3C WG (Adobe versus the world)
  
• XMLHttpRequest support for GET, POST, PUT, DELETE is fairly consistent across browsers
  
• XMLHttpRequest is not compatible with cross-domain requests without server-side cooperation 
  
• In the interests of security, most web servers disable PUT and DELETE and many administrators are loathe to enable them
  
• Storing state entirely on the client would require the transmission of and local storage in inherently insecure ‘containers’ sensitive data, yet not storing state entirely on the client immediately breaks the stateless property required to be considered REST.  
  
• Implementing truly RESTful APIs would impact almost every aspect of the environment in which we deploy applications; some changes would be for the better, some not so better.

So developers are sitting between a rock (variability in standards and support) and a hard-place (regulations, risk management, security, web ops concerns). REST is a great concept, and it’s based on established, ubiquitous standards but the problem is that it’s an ideal that does not necessarily take into consideration the environment in which such an architecture would need to be implemented. So it’s no wonder developers have done what developers have always done – worked around the constraints to get the job done. Because you know as well as I do (because you’ve had these conversations, just like I have) that the conversation went something like this:

Developer: We can’t implement a REST API without PUT and DELETE support enabled on the web servers, and we’ll have to store customer information in cookies to maintain a stateless set of operations… oh, and we’re going to increase the size of data because we need self-descriptive messages so the app might run slower on mobile devices.

Info security: No way, we are NOT opening ourselves up like that. Security, you know. Risk. Prison. The CTO wouldn’t look good in blaze orange.

Web ops: What the infosec guy said. Are you kidding? Enable PUT and DELETE? And how large are these messages going to be? Will we need more bandwidth, cause the network guys say we’re already at 60% of our allowed utilization and we can’t have any more because it’s starting to interfere with success of the soft-phone rollout project. 

Business Stakeholder: We need this application and we need it on time.

Marketing: A REST API is tablestakes. We must have one.

Developer: We can’t implement a REST API any other way. REST requires certain architectural characteristics and in the end it will scale better and we’ll have better visibility and -

Business Stakeholder: [eyes glazed over] We need this application and we need it on time, surely you can do something…

Developer: Well, I suppose we could just use GET and POST and then normalize PUT and DELETE as parameters or headers instead.

Web Ops: Excellent! Sounds like you’ve got the problem in hand then, I’m out.

Developer: And we can maintain state in sessions like we always have…

Info security: Excellent! Sounds like you’ve got the problem in hand then, I’m out.

Business Stakeholder: By the way, we’d like to demo the application for user feedback at our next <trade show/user group/shareholder> meeting. Think you can get it done a few weeks early?

Developer: We’d have to work overtime and weekends so -

Business Stakeholder: Excellent! Sounds like you’ve got the problem in hand then, I’m out.

Marketing: By the way, we can still call it REST, right?

And the next thing you know there’s an API available that tries to maintain the spirit of REST while very loosely following the letter of REST. As developers, sometimes we are forced into implementing solutions that break the rules even though we’d prefer to follow them. Cause in the end developers have to serve the needs of the business while working within the constraints of reality – and that means security and regulations and audits and limited bandwidth and other architectural limitations that may force architectural compromises that result in a less than ideal architecture, but a still secure, fast, and efficient application that serves its intended purpose.

The solution is, ultimately, just to not call such APIs REST. Nor RESTful, nor even REST-like. In the same way that we shouldn’t be calling every web-based application “cloud computing” we shouldn’t be calling APIs “REST” when they really aren’t. The argument that what we’re calling today “REST APIs” are really “NO WS-* APIs” is fairly accurate. But to call them simply “web services” would certainly confuse them with their SOAPy counterparts and cause the other side of the fence to rebel just as fiercely.

So until someone comes up with a better name that sticks, we may have to fall back on the tried and true “formerly known as” formula. I propose the “Formerly Unintentionally Counterfactually Known as REST” API.

It still has REST in the name, so marketing should be happy with that, right?