
Amazon proves that REST doesn’t matter for Cloud APIs - chanux
http://stage.vambenepe.com/archives/1700
======
cemerick
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.

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

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

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

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

------
sriramk
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 :)

~~~
aaronbrethorst
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...](http://www.flickr.com/services/rest/?method=flickr.galleries.addPhoto&api_key=123456&gallery_id=123456&photo_id=98765)
(note: HN is truncating the displayed link.)

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

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

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

~~~
eterps
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.

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

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

~~~
tybris
EC2 uses SOAP, no one cares.

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

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

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

------
_stephan
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?

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

[http://en.wikipedia.org/wiki/Representational_State_Transfer...](http://en.wikipedia.org/wiki/Representational_State_Transfer#RESTful_web_services)

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.

~~~
_stephan
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?

~~~
byoung2
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?

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

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

