

SOAP vs REST: The war between simplicity and standards - lmacvittie
http://devcentral.f5.com/weblogs/macvittie/archive/2008/12/05/soap-vs-rest-the-war-between-simplicity-and-standards.aspx

======
alexandros
It's kind of hard to produce a calm response to this article but i will try my
best.

For one thing, SOAP (an envelope) cannot be compared to an architectural
style. A better correspondence might be:

Architectural Styles: REST vs. RPC

Protocol Stacks: RESTful HTTP, ATOM etc. vs. WS-*

Envelopes: HTTP headers(?) vs. SOAP

For another thing, claiming that ws-* is standards based while REST is not is
plainly false. Whereas ws-* includes 50+ not wholy compatible specs, REST is
based on few but well corelated specs (XML, HTML, URI, HTTP). The number of
spec-pages produced is completely irrelevant. In fact, like lines of code, may
be counter-productive. A better measurement may be 'interoperability
produced'. On this test, the benefits of REST shine in large distributed
systems such as, say, the web.

------
justindz
The article seemed a bit weak, since depending on the problem set the choice
is either apples and oranges or completely moot. Saying that HTTP + JSON is
going to throw your developers for a loop is a bit embarrassing. The "hard"
part is always in the data model itself, inside the container, which isn't
magically solved by a given transport or serialization approach.

I've been the client to a few SOAP services which were "standard" but which
contained object representations implemented by people who probably learned
XML while severely inebriated and chose their tags vs. attributes using some
Post-Its and a dart board.

~~~
dablya
Can you suggest some resources that provide guidelines for choosing
tags/attributes?

~~~
justindz
Hm. I've never used any. The issues I ran into were along the lines of SOAP
output with XML structures that alternated within the same document using
attributes or child nodes for properties of the object (likely, the overall
response was a result of two different programmers' output and they didn't
compare notes).

There were also some instances of things like a parent having a child node and
the child having a name sub-node instead of a name attribute on the child,
where the parent had a name attribute. I realize there are no inviolable rules
about when to use an attribute versus a tag, but what I ran into was
inconsistency within a single response object. My point above was that the
envelope is a standard, but the contents can be poorly designed and is domain-
specific--the same is also true for REST.

~~~
dablya
My understanding of the standards around SOAP, the ws-* ones, is that the
don't promise standardization of the payload. The aim is to provide standards
for integration, and those are useful, because tooling and infrastructure
around the services can be reused. SOAP standards are there to simplify
integration, they say nothing about the payload (other then maybe it having to
be xml)

------
trezor
Looking at the poll on that site I'm obviously pissing against the wind, but
if you have a decent web-framework exposing your services standarized using
SOAP involves absolutely no extra effort. None.

I can see lots of people disagree and I might even be in the minority here on
HN, but I think REST is to SOA what PHP is to the web: Quick to learn, simple
to get up and running, but half-assed and non-standardized and thus bound to
get messy.

~~~
jamess
Yes, I'm afraid you are. SOAP is out of control. You can tell how bad it is
getting since it was originally named "Simple" which even back in the day was
a misnomer. The fact that all mention or pretence of it being simple has gone
out the window is symptom.

Here's a particularly egregious example of a SOAP structure I'm familiar with
but I must stress I did not design:

<?xml version="1.0" encoding="UTF-8"?> <SOAP-ENV:Envelope xmlns:SOAP-
ENV="<http://schemas.xmlsoap.org/soap/envelope/>"> <SOAP-ENV:Body>
<MarkLastPhotoInRollResponse xmlns="<http://localhost/api/soap/eyefilm>" />
</SOAP-ENV:Body> </SOAP-ENV:Envelope>

That's what? More than a hundred bytes of data to encode what can only be
described as one byte of payload? Insanity.

REST has some good points to make. There's a lot of importance in not trying
to impose excess state in applications that are primarily going to be used
over HTTP talking to traditional web servers. However, the best thing about
REST is that it doesn't say _anything_ about how the data ought to be encoded.

Of course people can abuse this by using pointless and stupid formats like
JSON, but hey if you don't want your application to have reasonable
performance, it isn't my problem.

Those of us who still have to worry about CPU cycles and RAM and the cost
bandwidth realise that you can define data formats that have useful properties
like streamability, that is to say you can define parsers with the semantics
/Either read this structure now if you have enough data, or call me back when
you do have enough so I can parse it then./ A property I consider paramount in
any asynchronous application that uses the network, but is completely lacking
in XML. That also gives you the option to skip structures without parsing
them, which is helpful. Then there are issues like widths of integers, which
people are inclined to forget about when using modern scripting languages. Of
course, this all comes back to bite people when they try to use a horrid
language like PHP which secretly actually has a fixed width for its integers,
but neglects to tell you what it is and has no syntax that lets you choose to
be signed or unsigned. _sigh_

