Ask HN: SOAP vs REST, which one do you prefer working with ? | Hacker News Reader

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

17 pointsolalonde18 comments

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 ?

View on HN

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.

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.

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

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.

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 :)

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.)

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.

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.

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.

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.

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.

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.

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.

http://stackoverflow.com/questions/686634/soap-whats-the-poi...

[Disclaimer: I answered here http://stackoverflow.com/questions/686634/soap-whats-the-poi... ]

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.

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.

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.

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.

Reply on news.ycombinator.com