

Ask HN: SOAP vs REST, which one do you prefer working with ? - olalonde

We are looking forward to build a web service and would like to know which  architecture HNers liked most. How hard would it be to implement both SOAP and REST ? Is there any framework that implements both "protocols" (for lack of a better word) seamlessly ?
======
arnorhs
REST wins. Hands down.

I generally find it very tedious to work with web services using soap.
Arbitrary variable types, complicated error reporting etc. You can fall into
all kinds of problems with different standards etc...

It's fine when you're a little experienced with SOAP (which I unfortunately
am), but I don't think it's a format for the future.

------
arethuza
The single most common SOAP interface that I have seen is something like:

string DoStuff(string request)

Where the request and the result are already XML documents!

SOAP has taught me to fear any technology that starts with "Simple" - it won't
be.

~~~
tobyhede
Yep, been there, done that. Sending bespoke XML string representations over
SOAP transport: priceless

------
wanderr
SOAP is ridiculously complex, which makes it annoying _and_ slow. Rest has its
own set of problems and annoyances, including lack of compatability with
browser plugins (because browsers don't expose the http codes), and the
awkwardness of trying to fit everything into the verbs offered by http, and
the fundamental lack of support for betching calls because the endpoint is the
method, etc, etc.

Rest was awesome when it was _the_ alternative to SOAP, but now there are
alternatives to both that are significantly better. My protocol of preference
is JSON-RPC 2.0. Simple, fast, compatible, handles batching, fairly human
readable but also quite compact.

------
olalonde
The consensus seems to be REST all the way (and not to implement multiple
interfaces to the same API). Thanks everyone for the feedback! We're building
this web service for people like you so your opinion is invaluable :)

------
mattdw
REST, please. You can generally bootstrap a REST client from any language with
basic HTTP and XML/JSON/… libs (ie. basically every language.) On the other
hand, doing SOAP without a dedicated library is a path to pain and suffering,
and not every language has such a library. Additionally, the complexity makes
it that much harder to find a _reliable_ library. (Python, for instance, has a
SOAP lib, but it's old and tends to not play at all nicely with .NET's
automatic SOAP services. Last time I tried to do that it ended with wailing
and gnashing of teeth.)

------
pquerna
I've hated being a _USER_ of APIs built on frameworks that output multiple
APIs, like SOAP/REST/XMLRPC all at once.

You end up with unnatural APIs in the 'REST' api.

Don't get caught up in the details of 'rest', focus on developing the API for
your users -- think about what Calls they need to make, make it simple,
document it!, give examples, keep the output formats sane (xml and json are
done easily now days), and you'll be miles ahead of most web services.

------
alexu
REST, because of forward and backward compatibility

SOAP is too strongly typed for most startups. Most likely you will be changing
your API quite a bit over next few years and with REST for each new version of
your API you have option of

1\. Create new entry point (new URL)

2\. Specify version in the HTTP headers

3\. Expand request/response spec with new elements

Because most SOAP libraries implement very strong binding to WSDL schema you
will be forced to create new entry point for every version of your service.
FedEx learning this hard way right now. They moved their API from REST to SOAP
and they have no clue how to update it now without breaking all the
developers.

------
ochekurishvili
SOAP annoys with XML request/responses.

REST is much better with simplicity, much acceptable by developers and much
more popular in tech-startups.

But there is an XML-RPC too, great solution but not spread as is has to be,
like REST.

------
dmharrison
Depends on who you expect to consume it I think. If you're going to have
enterprisey folks use it then they're most likely going to want SOAP etc, if
you expect it to be used in service orchestration ...... then the people with
that kind of skillset tend to end up using SOAP etc. General consumer access
REST all the way. I've wrote a custom service that did both as there was
nothing at the time that did both, but that was ~4 years ago. The REST service
was never really used, I think that because for your average joe sitting there
in a corporation, the training and toolset he's got is all SOAP focussed for
the most part.

------
vsync
I actually quite like XML-RPC.

SOAP is too complicated for simple services and from everything I've seen REST
only defines the URL layout while the format of the data is up to you. So you
end up sending some XML-RPC like thing over the transport.

Then there are issues like GET requests getting arbitrarily limited in size,
character encodings, and stuff that makes it not even worth trying to do
function calls (even idempotent ones) with anything but POST.

I wish it were otherwise.

~~~
Shaping
This is interesting. I like REST for its URL resource name-space idea, but
less so for its lack of specificity/standards for choosing media types and
doing security. Concerning the GET limitations specifically, what problems
were you having with size and character encodings? This makes me think that
the REST verb-structure-as-hyper-media-CRUD model is broken from the start, in
terms of scalability.

~~~
vsync
I believe URLs are limited to 1000 or 1024 bytes, or are in practice on some
browsers (probably IE of course), and are either limited to 7-bit ASCII for
strict compliance or the character encoding is just undefined. It's been a
while since I looked at the RFCs in detail on this and I'm sick right now so I
apologize for the lack of detail.

------
jonsmock
[http://stackoverflow.com/questions/686634/soap-whats-the-
poi...](http://stackoverflow.com/questions/686634/soap-whats-the-point/686662)

[Disclaimer: I answered here [http://stackoverflow.com/questions/686634/soap-
whats-the-poi...](http://stackoverflow.com/questions/686634/soap-whats-the-
point/686662#686662) ]

------
mseebach
The promise of SOAP is really cool, but I've found that you end up making
countless special cases and arbitrary error handling anyway.

The more complex and potentially fragile the in- and output of your service
is, the more attractive XML becomes, since XML can be independently validated.
If you have no such needs, REST will do just fine for almost anything.

------
kls
To answer you other question, yes their is nothing precluding you from using
both. I know off the top of my head that Java has JAX-WS and JAX-RS which
provide SOAP and REST endpoints respectively. Most languages and frameworks
will have something similar.

------
tobyhede
REST.

So much easier to explain and consume.

Plus, a modern framework like Rails essentially bakes the REST API in for you.
Some of my apps are now really consumers and coordinators of Ajaxified JSON
requests backed onto Rails.

------
jjs
REST, by a mile.

I've written programs and frameworks that handled both SOAP and REST before,
and no, you can't have them, because SOAP needs to die.

