SOAP vs REST: The war between simplicity and standards

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

by lmacvittie • 18 years ago

6 7 18 years ago

devcentral.f5.com

trezor• 18 years ago

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• 18 years ago

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

justindz2• 18 years ago

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.

dablya2• 18 years ago

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

justindz2• 18 years ago

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.

alexandros• 18 years ago

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.

SOAP vs REST: The war between simplicity and standards

Related Stories