Capability trumps everything else.

If AWS sucked, or was merely a typical collection of services, then details about its API design might matter. Of course, AWS isn't typical – it's exceptional. Thus, its API could require the use of carrier pigeons and people would still be lining up to use it.

That said, nicer APIs are nicer. As someone that has programmed directly to EC2's APIs, I so wished they were less crufty. I now use jclouds (via pallet), so I thankfully don't have to think about such things anymore.

I find that RESTfulness improves the quality of design by forcing a little consideration on how to represent resources and actions on resources. The alternative is often littering the API with actions anytime a new one is needed - once that first version is out in the wild, it becomes a lot harder to take the time to consider the design choices. REST gives you a conceptual framework in which to implement new functionality.

In addition, all the consumers get the benefit of a common specification - if you tell me your service is RESTful, I can probably start making requests without even knowing much more than a starting URI, because I know how GET, POST, PUT, and DELETE will behave; I know what the error/success codes are going to look like; I can guess that Content-Type is going to drive the input and Accept will drive the output.

Sure, the consumer is probably going to leap through whatever hoops I put out there if they want my data, but RESTfulness is a courtesy, extending a hand and saying I'm not going to make extra work for you.

In the case of the OP, I'd say "Amazon proves that people who want to use a well-designed and beneficial service will work with whatever they're given".

Amazon's API format is irrelevant because their service is so popular. Once the API is stable and client libraries are available for common languages most developers will be unaware of the actual mechanics.

If you're launching a startup then you don't want to give your early adopters an excuse to not work with your API. If you're developing an API for internal use then you won't be using an off the shelf client library in any case.

Furthermore, a clean API is a sign to other developers that you know what you are doing. If you are targetting an industry where coders get a say on whether or not they will choose your service then you'd better put your best foot forward. I've seen far too many APIs that show a company has no clue on the technical side, which causes me to cast doubt on other parts of their service.

S3 is a superb example of a REST API, and is a key example in the RESTful Web Services book.

EC2's API is awful, inconsistent, and the subject of the article.

The OP is completely correct. I designed a bunch of the Windows Azure APIs - we spent a lot of time making sure they were RESTful. Looking back now, I think it was a big waste of time. Almost everyone uses the API through some custom library and I doubt it would have mattered if we hadn't taken the trouble.

I'm involved in some API design again and I sent out a mail saying that any discussions involving whether option A or option B is the more 'rest-ful' thing to do will get smacked down :)

Hey Sriram - When are we getting coffee? I'll code against Amazon's gnarly API because I have to, not because I want to. Flickr's another great example of this. I mean, seriously, look at some of the calls, here: http://www.flickr.com/services/api/

I think it's way more logical to POST a photo_id to http://flickr.com/galleries/123456/photos than to POST to http://www.flickr.com/services/rest/?method=flickr.galleries... (note: HN is truncating the displayed link.)

Then again, I don't think I'm in the target demographic for Azure.

So you don't care about those writing custom libraries?

From personal experience where I work (mobile apps company) I can say that a RESTful API is a good choice usually in terms of familiarity and reuse of code. We usually work with RESTful APIs, so when a new one comes, we already have our internal libraries to handle it, speeding up development.

But we work with other kinds of APIs as well, when a client asks. Apart having to do more work since we don't have code to reuse for that, we have no other problems.

If it works well, it does not matter if it's RESTful or not. But as for everything, if you are familiar with something, you are usually faster and more accurate.

If you ignore the APIs, AWS still has a substantial number of merits which make it a formidable player. It is a huge leap to say that because the market has smiled on AWS, we all love everything about it and wouldn't prefer more of it be REST-ful.

Exactly, if there was a similarly priced alternative to AWS that has a fully RESTful API I'd choose the one with the RESTful API.

There's not really a very consistent AWS API. Some services are very restful, others are not.

"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."

I think whether you have REST or REST-like (i.e. RPC over HTTP) doesn't matter so much, as long as it's not SOAP.

That's what people are lauding.

EC2 uses SOAP, no one cares.

Is the headline a deliberate echo of Dick Cheney's famous observation that "Reagan proved deficits don't matter"? Or a rhetorical malapropism?

Are there more reasons than just "it's simpler" and "Amazon did well without it"?

The RESTfulness of an API is of very low concern on how I choose a service to use and the quality of the service is paramount.

If the API lets me get things done and/or provides an abstraction library in my language of choice so I never have to see it, I really couldn't care less how it is written.

Does REST make more semantic sense? Of course, but if your app has no features or consistently loses my data, I couldn't give a shit.

Could maybe someone give a concise definition of what makes an API RESTful and explain why the AWS Query API is not RESTful and how a RESTful API would be better?

Take a look at Wikipedia's description, for example:

http://en.wikipedia.org/wiki/Representational_State_Transfer...

Applying this to one of Vambenepe's examples of an AWS method--

"AWS mostly uses RPC over HTTP. You send HTTP GET requests, with instructions like ?Action=CreateKeyPair added in the URL..."

you can see that it's not RESTful. A RESTful version of this method would have something like "KeyPairs" in the URL path rather than in the query string, and it would use POST rather than GET to signify a create operation.

URLs really have very little to do with REST beyond uniqueness, even though it is popular in "RESTful" APIs to encode objects in URLs. A POST /keypair/create or whatever could just as well be POST /1234567890123. The important bits of REST are representations, state(lessness) and relationships or links.

I think the best place to start from would be the Fielding dissertation: http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch....

Thank you, it's nice to have another member in the REST sanity brigade: http://searchyc.com/comments/%252Brest+hypertext

Thanks for the pointer. I read the Wikipedia page, but I found the explanation of the general concept too abstract. The definition of a RESTful web service further down the page is much clearer.

However, does it really make any practical difference whether the API makes full use of all the HTTP methods (GET, PUT, POST, DELETE)? Sure, it may be a bit of an abuse of the protocol to encode everything as a GET, but since you usually don't want any caching when using such an API, does it really matter?

I'm designing a RESTful api at the moment and using get, post, put, and delete to represent select, insert, update, and delete gives users a clear pattern when new features are added. Right now say there are just photos in my app. Post json or XML to /photos to create a new one, put to /photos/123/ to update. Now I announce that I'm adding videos. The pattern is exactly the same, the URL is just / videos. But I suppose you're right, I could achieve the same effect with ?object=video&action=createNew, but why make users learn a new vocabulary?

Yes, because when you don't play by the standard rules, it's hard to find others to play with you. Cache servers are just one example. Another example: web browsers. Note that web browsers are still useful against REST services, even if they don't have good support for PUT or DELETE.

In general, REST provides discoverability and interoperability that you don't get without a uniform interface.

Lots of things succeed despite being inelegant, but that does not mean it's not important to be elegant.

Amazon can afford to have an inelegant API as they're already dominant (and when they launched, they didn't have many competitors).

If someone launching an Amazon EC2 competitor today strapped together a pig-ugly set of RPCs over HTTP, I doubt it would encourage its use.

Elegant APIs are a sign that you respect developers.

Aside from the blatant strawmanning of the article, consider a rephrasing:

"Every time a new API is announced, its 'nice-to-work-with-ness' is heralded as if it was a MUST HAVE feature. And yet..."

People work with what they have available to them. If another service came into existence that was in all respects the same as EC2, but had a nice, RESTful API, it would have an advantage.

Barring that, people use EC2.