The case for REST?
by Mark McLoughlin
Hi,
I've been reading about REST and trying to put together a convincing
list of reasons why we should choose it over SOAP:
- There's a lot of buzz about it right now - twitter, flickr,
facebook, S3, deltacloud etc. are all basing their APIs on it[1]
- RHEV-M runs on JBoss and there's a significant REST push in the
JBoss community (lead by Bill Burke) with RESTeasy, REST-* etc.
- It makes APIs very easy to understand and play with - just look at
some of the popular RESTful APIs ... you could imagine doing
something fun with them after 5 minutes hacking
- A RESTful API is largely self describing - e.g. the XML/JSON
representation of a VM would include links for each VM action
available
- In theory, there should be less interoperability issues because of
the simplicity
- Resources are addressable - you can imagine all sorts of
interesting possibilities from being able to pass around a URL for
a VM, for example
- Easier to consume RESTful APIs in AJAX apps
And then there are a whole heap of advantages REST advocates shout about
which I'm finding hard to get excited/convinced by:
- Because you're not abusing HTTP as a transport protocol, standard
HTTP constructs can be used - caching, proxies, gateways etc.
- The web scales really well, so RESTful APIs will naturally scale too
And some disadvantages:
- At first, it looks trivial to design a good RESTful API ... but the
more I read, the more really subtle issues[3] there are to think
about - you only need to look at all the controversies about
various APIs being denounced as not truly RESTful
- Similarly, what we essentially want is an RPC API, but thinking
about REST as just another API protocol almost guarantees you'll do
it wrong
- It doesn't look like there is the same level of auto-generated
client bindings available as there is with SOAP/WSDL[4]
Perhaps it's just a case of being turned off REST by the elevated levels
of hype and the angst-ridden battles going on over just what is and
isn't RESTful[5]
Cheers,
Mark.
[1] - Well, they claim to be - and then at least some of them are
denounced as being not "truly" RESTful
[2] - Nice where certain actions are only available to certain users,
now thank I think about it
[3] - Simple example - POST apparently should be idempotent, so for the
"create VM" API, do you require the client to generate an ID and ensure
reject multiple requests with that API e.g.
=> POST /vms/
<vm>
<id>XXX-XXX-XXX</id>
<name>foo</name>
</vm>
or do you have POST generate an ID, which you then PUT to:
=> POST /vms/
<= HTTP/1.1 200 OK
Location: /vms/XXX-XXX-XXX
=> PUT /vms/XXX-XXX-XXX
<vm>
<name>foo</name>
</vm>
[4] - Although ... my guess is the auto-generated bindings are never
that nice and wrapping the auto-generated binding with a more natural
API for the language would be a similar job as wrapping a REST API
[5] - e.g. I find it very hard to see why I should care about most of
the points here:
http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
14 years, 1 month
IRC
by Mark McLoughlin
Hey,
I've created a #rhevm-api channel on irc.oftc.net, please do join us
there
Cheers,
Mark.
14 years, 1 month
REST or SOAP : scripting languages, a case for Perl
by Jérôme Fenal
Hi all,
for this choice, what are the expected scripting/dynamic languages
APIs to be supported ?
For Satellite/Spacewalk, lots of users are Perl users, and proposing
SOAP solely could left those users (including myself) behind, as
SOAP::Lite is not really on par with what Java can offer.
Furthermore, current competition users already have a Perl API, which
could leverage these skills as well with RHEV-M.
I don't know what Python or Ruby (besides JRuby) can offer here, but
these should be considered as well when defining the API access
protocol.
My 2 cents, to start the conversation,
J.
--
Jérôme Fenal - jfenal AT gmail.com - http://fenal.org/
Paris.pm - http://paris.mongueurs.net/
14 years, 1 month