

Ask YC: is SOAP vs. Rest the new Emacs vs. Vi? - c1sc0

I've noticed the SOAP vs. REST - style webservice debate pop up again and again over the last few years. Which style of webservice do you prefer to offer/use? Why?
======
inklesspen
My view:

SOAP is for people who bought the "XML is the universal language" line of
bullshit.

REST is for people who know how HTTP actually works.

~~~
johnm
Naw. The de facto paylod for RESTful services are XML. Though, yes, that is
called the POX (Plain Ol' XML) on REST.

REST is the only thing that has been actually proven to work at internet
scale.

SOAP is just the latest version of CORBA, for the web.

~~~
inklesspen
Really? I've seen an awful lot of JSON services.

~~~
johnm
JSON is the "new hotness" for a lot of people but the default is still XML.

Also, note that depending on what format the underlying data is in, using JSON
can actually be worse for performance than POX (escaping, etc.).

------
sah
The reason that SOAP vs. REST isn't like Emacs vs. vi is that both Emacs and
vi are pretty decent.

Read the text of a SOAP transaction sometime. Or, more realistically, just
read the first kilobyte or so. It's ridiculously over-engineered, and should
just never be used. REST is a good example of how much simpler it could be.

------
wastedbrains
I am sure there are still some people fighting about it, but mostly what I
have heard is REST won. Amazon says 80% of the api calls are REST, I believe
Google has been moving more toward REST as well.

After working with both (admittedly only a bit), I quickly decided REST was
just far simpler.

Is there specific reasons you see advantages in some SOAP capabilities that
you don't think REST would handle well?

------
andrewf
I've implemented a small (in terms of number of supported calls) read-only web
service which has SOAP+WSDL, REST/XML and REST/JSON frontends.

From the server development point of view: SOAP is a giant pain. Randomly
selected SOAP implementations are just not likely to interoperate. We
eventually coaxed PHP5's SOAP server stuff into talking to both .NET 2.0 and
Java (with Netbeans 5.5's J2EE libs) clients - IIRC we recommend SOAP 1.0 for
one, and SOAP 1.1 for the other.

A week after we finished Netbeans 6.0 was released, and the SOAP client stuff
that's bundled with it wouldn't play well with our server.

From the client end: /if/ you can actually talk SOAP successfully, things work
nicely. You just call the generated stubs and the RPC happens transparently.
If I was calling our web service from C# I would choose SOAP every time.

The REST stuff would be a pain to use if you had to use the DOM to read the
XML that comes back, because, well, the DOM is painful. If parsing what comes
back isn't a pain, REST works well. For internal clients, we prefer REST/JSON
with the standard PHP json parser.

------
benreesman
Can someone please explain to me how REST is anything but a pompous name for
HTTP? Or how it has applicability to any kind of service other than document
management? All of the criteria stipulated in chapter 5 of the Fielding
dissertation are spelled out in the RFCs that describe HTTP and related
technologies, and _they only apply to documents_. There are other verbs that
need to be applied over a network.

I think the (sane) pro-REST argument can be summed up in the following: 'HTTP
is a wonderful way to do CRUD operations over a network. Wouldn't it be cool
if there was a catchy word to remind people that HTTP has a lot more to it
than most people are aware of?'. This bollocks about REST being able to
replace RPC is like having an argument about whether cars of airplanes are a
better way to get around. And please stop torturing your service models to
look like URLs just to be fashionable (I know, if I want upmod a comment I can
POST to /comment/1234/karma/new! No, 'Upmod' is a distinct verb that doesn't
have anything to do with GET or POST or PUT or HEAD or DELETE). If the thing
you are modeling isn't a document in any sense, then don't try to model it as
one.

What I think people really mean when they say REST is 'ad-hoc RPC over HTTP
using reasonably lightweight serialization', which is quite a lovely idea in
its own right. The decision about using SOAP or a more lightweight RPC really
boils down to the languages on each side of the wire. If the languages are
structurally typed with object literal syntax then you want to use something
lightweight, as the impedance mismatch between a literal Ruby datastructure
and JSON is low. If you are connecting two nominally typed (often early bound)
languages then you want SOAP, because if you're into that bondage and
discipline thing then you need a WSDL to make sure that no one's boundaries
get crossed. And pulling the result out of an HTTP response in Java is a lot
easier with Axis than trying to parse some loosely specified JSON blob (unless
you're coding in Perl, in which case I'll take the JSON blob any day).

Don't debate SOAP/REST, if you must have some silly religious debate between
two technology stacks which are both reasonable tools well suited to certain
activities then at least debate Java/Python, the appropriate choice of RPC
philosophy sort of falls out.

~~~
johnm
Ouchy. Basically, it looks like you're taking a very narrow view of REST and
conflating lots of it with historical RPC-ish thinking.

Re: There are other verbs that need to be applied over a network.

Please name one that's actually needed.

~~~
benreesman
> Ouchy. Basically, it looks like you're taking a very narrow view of REST and
> conflating lots of it with historical RPC-ish thinking.

My view of REST is narrow only in the sense that I've actually read the
document where the term originated, which gives a rather precise (in places
mathematically precise) definition of the term. If this level of rigor
interests you then you can find this document at
[http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch...](http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm).
There only thing that is 'historical' about RPC is the thousands of real-world
applications implemented in this style in every conceivable area of
distributed computing over the last 3 or 4 decades. Whole programming
languages both academic (Newsqueak) and industrial (Erlang) are premised on
the notion of distributed message passing and you will be hard pressed to find
any nontrivial distributed system that doesn't require the ability to invoke a
verb over the network (including HTTP). From Fielding's dissertation:

'The primary distinction between network-based architectures and software
architectures in general is that communication between components is
restricted to message passing [6], or the equivalent of message passing if a
more efficient mechanism can be selected at run-time based on the location of
components [128].'

HTTP itself is a form of RPC, with distinct named methods and a way of passing
arguments and retrieving results. Hard-line REST advocates fall into one of
four categories:

1) They believe that HTTP is a wonderful RPC protocol for doing CRUD on
entities that can be roughly called 'documents', but would never dream of
trying to torture some dramatically different domain into this model. When
they are writing services that are document processing services they write
them in a 'RESTful' style, and they otherwise never do. 2) They believe that
all network transactions can be sensibly accomplished with a model that has
only GET, PUT, POST, HEAD and DELETE, and that uses them as originally
intended. 3) They believe that any software system that can't be accomplished
as with (2) above isn't worth writing. (Web 2.0 with Rails anyone?) 4) They
don't know what REST means.

If #2 describes someone then he or she is inexperienced or stupid or both, if
#3 describes someone then he or she is a fashion-conscious Web 2.0 asshole who
will only ever receive money that came from a venture capitalist and never
money that came from a customer. Ever. And if #4 describes someone then he or
she really ought to read the literature before posting flippant drive-by
commentary to Hacker News in what can only be some lame attempt at karma-
whoring on the fashionability of the word 'REST'.

> Please name one that's actually needed.

Before replying to this I need to make it explicitly clear that I can only
reply to what I think you're actually saying, so excuse (and correct) me if I
reply to something that you didn't actually say. It sounds to me like you're
proposing that GET, PUT, POST, HEAD, and DELETE are the only verbs that anyone
should ever be interested in invoking over a network. Now there is a sense in
which they might be sufficient for most transactions since you can attach an
arbitrary payload to a POST and receive and arbitrary reply, but I think
almost anyone would agree that this falls under the point made in my original
post about the fact that people actually just want lightweight RPC when they
talk about REST.

For the sake of argument I'm happy to propose something that people might like
to do with a web-service that doesn't fit a document CRUD model: play chess.
Now while you may be able to GET a description of the current board with some
resource identifier like /chess/game/1234/board, you will no doubt also want
to MOVE and maybe even CONCEDE, and the moment that you've started POSTing to
URLs that look like /chess/game/1234/move or /move/new you're right back to
POSTing to a URL with another method name in it, i.e. lightweight RPC over
HTTP and it's not REST anymore. The chess example is arguably contrived (and
arguably not) but it doesn't take much imagination to start picturing web
services for the remote compilation of code, or the provisioning of mobile
devices, or calibration of remote underwater sensors. Just because a bunch of
people have decided that social-networking is the most demanding application
that we as developers should ever contemplate doesn't mean that the ability to
do distributed message passing and procedure call is obsolete. Plenty of
people are making plenty of money doing just that.

~~~
ratsbane
In a RESTful world you might thing of moving a chess piece as POSTing a new
location value to /chess/game/1234/piece/. To concede, You could POST a
"concede" flag to /chess/game/1234. That seems to me like the simplest way to
state the actions, but I'm sure there are many semantically equivalent ways to
accomplish the same thing.

~~~
benreesman
When you say out loud or write in English what you intend to do you will say
'I moved my piece from b2 to b3'. When you invoke a method to accomplish this
inside of a single process you say (move piece :b3) or piece.move(:b3). Why
then, when the network gets involved do we do the semantic gymnastics to
recast this to 'I posted a document describing a move that a piece could take
to a resource identifier describing such a piece'? Why would 'piece' even be a
distinct resource in the first place? What would come back if you GET a piece?
I'll argue that 'piece' is only a resource so that it can serve as the
implicit first 'self' argument to the 'move' method call.

My assertion is not that it is impossible to torture some domain into a
document centric model, I'm just saying that the limit of your motivation for
doing so as the distance from 'document' to your specific domain goes to
infinity is 'fashion'.

~~~
ratsbane
REST does have an advantage over SOAP in that it more easily takes advantage
of the properties of the HTTP over which it runs: verbs, caching, etc. With
REST it's very easy to separate requests which change data from those which
don't. Also, it's usually more concise.

I think it's easier to code for REST than SOAP, although, by choice, I've done
more of it. I have worked on some SOAP processes; while I concede it's easier
to drag-and-drop SOAP objects in an IDE, the verbosity of the ensuing
transactions makes it easy to overlook errors and much harder to fix them.

It may be more fashionable to use REST (although I know of some circles where
the opposite is true) but just because a trend is growing doesn't means it's
bad. REST seems like more of a grass-roots trend while SOAP is more something
that's sold to its users (that's just my impression; I'd be glad to hear
arguments to the contrary.) There are a lot of technologies you could describe
as more "fashionable" because their use is growing - but their intrinsic
merits or suitability for an emerging purpose might be the cause of that -
e.g. the web, email, pork-based cocktails. Er, strike that last one.

~~~
benreesman
I'm not generally an advocate for SOAP. SOAP is good for basically one thing,
which is sending Java/C# objects over HTTP and having them arrive on the other
side looking the way you expect. My preference for languages like JavaScript
leads to a preference for lightweight (mostly JSON-bearing) web services that
most people would call REST. I agree that SOAP has been the subject of way too
much promotion of the part of tools vendors trying to sell bloated web-
services stacks.

The reason for my rant is that REST has become a battle-cry in some kind of
reactionary anti-vendor uprising, which obscures the issue. The word REST has
a very precise meaning and almost all of the celebrated 'REST' services
(Flickr, Amazon, Facebook, etc.) fail to meet the criteria. Those services are
just lightweight RPC over HTTP, and there's nothing wrong with doing a service
like that. For client programs written in 'dynamic' languages, those kind of
services are preferable.

REST is for documents, and time spent trying to find the 'resource' to be
POSTed to in 'finalize this multi-step transaction between these two interest-
bearing accounts' is time wasted. The linguistic gymnastics necessary to jam
an RPC peg into a CRUD hole just make the service developer look silly.

Cheers.

~~~
johnm
Indeed, a lot of the services touted as RESTful are less RESTful and more
RPCish.

REST has certainly become a fad term that's used to hype that anti-SOAP
juggernaut and that's led to a lot of confusion since so many of the folks
doing the yapping don't really understand REST.

Your confusion (whether you've read Roy's dissertation or not) seems to be a
fairly common one for people coming from an experienced RPC mindset. I had a
similar conversation at SDWest after my talk on REST with a SOAPer -- he too
was missing the point that terms like "document" and "resource" are much more
abstract in REST than what the general English meaning implies -- particularly
to people who's existing experience with RPC approaches like SOAP and CORBA
before that gives them a very different and, arguably, much more concrete
terminology for RPC.

------
c1sc0
What about the documentation angle? SOAP supporters claim that WSDL removes
the need for custom-written documentation if combined with something like
javadoc. REST inherently needs more documentation which makes things harder to
maintain. Or so they claim ;-)

Anyone know a nice way to expose a webservice as SOAP/REST/XML-RPC & write the
documentation automatically?

~~~
johnm
Bah! The only thing that e.g. WSDL brings is that the "contract" for the
service can be baked into the legal contract between partnering organizations.
For big paranoid companies where people need a lot of CYA, that can be a big
point.

Good RESTful approaches are actually self-documenting. As the example from my
recent talk on REST at SD West shows, it's really easy to support human
discoverable (i.e., well documented) RESTful solutions. In my example, hitting
the root resource returns a page (in html or text) that shows how to interact
with the resource with actual examples. That's way better then some horribly
verbose WSDL that somebody is going to have to look up.

~~~
andrewf
If someone's writing a client in an IDE, WSDL gets them code completion.

~~~
johnm
<insert snide comment on IDEs vs. Emacs/vi />

More seriously, another problem with the SOAP approach is that a lot of the
toolchain'ish malarky around it hides reality from the developers and so they
tend to create even worse abominations.

------
Tichy
I only ever see articles proclaiming REST is better. Maybe that is because my
primary news source is news.yc.

~~~
johnb
It's because no one uses REST and then choose to go back to spending days
making java axis web services and .net clients play well together with ugly
hackish custom soap extensions.

Or maybe I'm just venting about my shitty week at work :)

~~~
c1sc0
Shitty week at work? Don't get me started ... that was the reason for this
thread in the first place: an 'enlightened' architect imposing Axis/SOAP &
then being surprised at the implementation-level problems.

~~~
geebee
I used Axis for some very minor work, and it wasn't too bad. I didn't get into
SOAP at all, but it seemed like a good and (by java standards) lightweight way
to turn a bunch of POJOs into web services quickly.

What are some of the bad implementation problems you've experienced or heard
about? Btw, I'm definitely not asking this to challenge the truth of your
statement (ie., I'm not looking for a response to pick apart and argue - I
would genuinely like to hear about some of the pitfalls you've seen).

~~~
c1sc0
I was initially impressed with the ease of converting some classes into SOAP
requests with axis, but after a while we got random service outages & bad
error handling.

From previous experience in the biological field I saw great plans, lovely (&
expensive) plans to develop grand services in SOAP ... that never actually
materialized ... & were converted to REST spitting out standard files.

I think the ideas of SOAP, WSDL & Co are actually very interesting but as a WS
consumer I've come to shun SOAP services.

In my opinion, human discoverability & excellent documentation are core to any
webservice. Maybe throw in some example implementations or lightweight
libraries specific to your service.

~~~
geebee
So far, our internal clients have been the only client for the axis-driven web
service, so I haven't really opened it up. In other words, we're really just
using axis2 for internal rpc-style calls. We also aren't transmitting much in
a soap message - really just the parameters to run. The bulk of data transfer
is handled through other methods.

------
sanj
It is more like Java vs. Ruby.

------
bosky101
i think u nailed it in the title yourself... 8 )

<humour>

there are people who use soap,...and then there's the REST of us :D

</humour>

