Over the years we have heard a lot about the benefits of REST for Web-based developments, particularly in the context of Web Services and more recently in terms of its relevancy to SOA. Therefore with the increase in use of Cloud, even if only at the early adopter stages, it was no surprise to see REST being adopted by various implementations.
Back in 2009, William Vambenepe considered the role of REST in Cloud and concluded that at that point in time Sun and Rackspace had APIs that were more RESTful than others. Well not quite two years later, with more development experience, more users and more choice, William looks at probably the most successful Cloud provider to date, Amazon, and asks the question (we paraphrase) "If Amazon doesn't use REST is it really necessary for successful Cloud?" As he says:
Every time a new Cloud API is announced, its “RESTfulness” is heralded as if it was a MUST HAVE feature. And yet, the most successful of all Cloud APIs, the AWS API set, is not RESTful.
Now you may disagree with William's assessment that we are far enough into using Cloud to assume this is not a coincidence, but it is an interesting situation to consider. Furthermore, William isn't suggesting that REST is not important, only that at least as far as Cloud management is concerned it simply is not important and does not offer any appreciable benefits over, say, RPC.
AWS mostly uses RPC over HTTP. You send HTTP GET requests, with instructions like ?Action=CreateKeyPair added in the URL. Or DeleteKeyPair. Same for any other resource (volume, snapshot, security group…). Amazon doesn’t pretend it’s RESTful, they just call it “Query API” (except for the DevPay API, where they call it “REST-Query” for unclear reasons).
As he points out, the lack of RESTful APIs has not stopped many people using it, nor has the scalability of deployed systems been limited or affected adversely. Neither has it impacted security or restricted the types of applications and languages that can make use of it.
Here’s a rule of thumb. If most invocations of your API come via libraries for object-oriented languages that more or less map each HTTP request to a method call, it probably doesn’t matter very much how RESTful your API is.
William points out that although an earlier article from the engineers at Rackspace comparing and contrasting the RESTfulness of their API with AWS is accurate, it doesn't seem to make a difference where it counts: with developers and users. In conclusion, he suggests that ultimately the RESTfulness of Cloud (at least Cloud management) does not matter as much as the simplicity.
The AWS API being an example of the latter without the former. As I wrote in my review of the Sun Cloud API, “it’s not REST that matters, it’s the rest”. One and a half years later, I think the case is closed.
His article has attracted many comments, most of whom disagree. For instance, one commenter states:
What you say isn’t false to my mind, although the success of EC2 has very little to do with their API, as John (comment #3) points out too. More generally though I’m not sure I like the sound of all of this. Would the Web be here today if Tim Berners-Lee had designed an interface – specific to physicists – allowing them to share results once they had installed some specific “collaboration software for physicists” on their machines ?
Another adds:
Your questions are great but they totally miss the mark: these details (like RESTful APIs) primarily affect library developers, and good libraries can abstract away any kind of API into something more resource-oriented. That requires someone able to map concepts effectively and consistently. Once good libraries are available, there’s not a great barrier for adoption and excessive misuse and waste are completely coincidental. It always comes down to consistency: as long as you’re able to provide a consistent interface, even if it’s not consistent with previously established concepts and mappings, an API will likely succeed given the product is worth the (extra) effort.
With more a more Cloud implementations being developed by vendors and open source efforts, their RESTfulness is usually mentioned as an important feature. But William's question remains: if the most successful Cloud vendor to date does not use REST, does it really matter?
Community comments
What's really important
by Rob Heittman,
REST and Mobile User Agents
by Paul Hanke,
Embrace the diversity
by Ross Mason,
Re: Embrace the diversity
by Steven Pena,
What's really important
by Rob Heittman,
Your message is awaiting moderation. Thank you for participating in the discussion.
The label "REST" has become broadly applied -- fairly or unfairly -- to web APIs that depend on basic HTTP semantics, and are not expressed in a more complex protocol that abstracts away HTTP.
As a REST advocate and, as such things go, I suppose REST expert, I don't really engage in wars of pedantry with vendors over whether all their services are optimally modeled as resources. Amazon's API is reasonably resourceful. Where it is more imperative and RPC-styled, they've valued comprehension and implementability over resourceful purity. For sure, it can all be accessed from a basic HTTP client, without having to incorporate SOAP, Protobuf, JSON-RPC, or any other RPC protocol. Some Amazon APIs are more resource-oriented than others. Amazon's S3 API, for example, was covered as an example in Richardson & Ruby's seminal RESTful Web Services book.
If a web API requires a special protocol to work, it is harder to adopt broadly, and its behavior is likely to diverge from the intrinsic properties of the web. These certainly are not deal-breakers for every application that exposes an API. But if I were designing an API for any general purpose cloud computing provider, I'd probably stick to the HTTP basics. I'd have to deeply examine any perceived advantages of promoting an RPC-over-HTTP protocol or library, and be utterly convinced that it was worth the costs.
As a consumer, I feel comfortable instantly with any vendor who exposes a "REST" API (meaning "implemented in HTTP" regardless of the purity of their resource model), and instantly suspect of any cloud vendor who's going to force me into adopting some RPC library or, saints forbid, a vendor-supplied API in software. I don't see this changing in the foreseeable future.
REST and Mobile User Agents
by Paul Hanke,
Your message is awaiting moderation. Thank you for participating in the discussion.
... the following comment quoted by Mark got me to thinking:
"More generally though I’m not sure I like the sound of all of this. Would the Web be here today if Tim Berners-Lee had designed an interface – specific to physicists – allowing them to share results once they had installed some specific 'collaboration software for physicists' on their machines ?"
... and one thought is this: would a REST API such as the Sun Cloud API have worked with the Web that TBL first created? ... that is, would the user agents (browsers) available back then have been able to make use of the custom JSON MIME types invented for this particular API? ... so the fact of the matter seems to be that to make use of the Sun Cloud API you either need specific 'collaboration software for cloud users' installed on your machine or else a mobile user agent (e.g., AJAX) that knows how to deal with the custom MIME types that the installed user agent (browser) by default has no clue about.
In the latter case (AJAX), the implication is that before a human user can make good use of Sun Cloud API URLs the human user must first find a mobile user agent that knows how to deal with the Sun Cloud API MIME types ... but the way that such mobile user agents are typically constructed, the user will not experience the Sun Cloud API as browsing over a related set of Web resources - those Web resources will in fact be hidden from the user ... in fact, the user may only ever experience accessing a single URL - that of the mobile user agent.
So, one argument for REST is that it doesn't break the Web ... and in fact, from a Web intermediary perspective this is true ... but here's a philosophical question: does the design of Internet resources that use custom MIME types that can only be understood by specialized software and/or mobile user agents break the Web from the user experience perspective? ... that is, does it break the Web when there are resources out there that the user can't meaningfully surf with a browser? ... that Google has difficulty crawling, understanding, and indexing?
I'm not going to try to answer that question, as I can easily see it being argued either way ;-) ... but I do think that to make the "Would the Web be here today?" argument for REST APIs - to include those that exclusively use custom MIME types (or custom HTTP verbs, for that matter) - misses the point that the Web probably wouldn't be here today if at the beginning everyone insisted on using their own custom MIME types ... (that's not to say that there are no good arguments for REST - simply that the "Would the Web be here today?" argument may no longer be one of them).
Embrace the diversity
by Ross Mason,
Your message is awaiting moderation. Thank you for participating in the discussion.
There seems to be a recurring urge to standardize REST in some way. I think the fact that REST is an architectural style not a standard is the reason it has been so successful. To emphasize this take a look at the enterprise. SOAP was developed to standardize communication between applications and clients and for many scenarios it failed. It failed because you cannot standardise communication in its entirety, misinterpretations of the spec, wildly different requirements and plain bad coding will break the chain. The smart decision by Tim Berners-Lee was to leverage a standard protocol to exchange data (HTTP) but only provide architecture guidelines for building REST applications. This left variance in the implementation, but ensured that HTTP would be the common protocol enabling interrop without forcing higher level standards like WS-*.
I've always felt that rather than standardising everything, its better to embrace the diversity and have better tools for dealing with the differences, since there will _always_ be differences in implementation. Integration tools such as Mule provide a good solution for consuming and produce many times of service including REST, WS, XML-RPC, etc. There are often valid reasons to use each of these types of services.
Cheers,
Ross
(disclaimer: I created Mule)
Re: Embrace the diversity
by Steven Pena,
Your message is awaiting moderation. Thank you for participating in the discussion.
SOAP failed? How so?