SOAP – Purpose and Invention

I have implemented a REST API before and I really liked it. In general when you implement REST over SOAP, your client/server is more orthogonal meaning that you can a lot more freely change the server without affecting your client(s). This orthogonality is due to using a more abstract and already well defined communication via HTTP verbs. Also, the use of hyperlinks embedded in your REST responses make it easier to extend and grow your API relatively pain free. Clients are supposed to follow these embedded links to get to new resources like a human would follow links on a webpage to 'drill down' for more information.

With that said, I had some coworkers who were told they had to use SOAP and they complained about it all the time. So I went into researching the two a bit more in detail.

In general what I found is that REST is well suited for highly distributed applications, when you have hundreds, thousands or millions of clients. One reason is the above mentioned orthogonality, another is caching that you get for free since you are using HTTP.

SOAP might be the quicker way to go when you need a smaller API for a client or two quickly and you are not too worried about scalability. It might also fit you better if you do not have an architecture that is structured around resources, because it might take you some time to restructure your app to even be able to implement REST.

If you are doing an AJAX heavy application then one pro about REST is you have the option of using JSON as your data-interchange format instead of XML. JSON requires less markup than XML so that would speed up your application since you would be sending less data over the wire.

It also seems that REST is over taking SOAP with web services, and its always a good thing to use a technology that is more widespread when you bring on new developers or if you want other developers to consume your data.

The pro for SOAP is that it already has structure built into it, but I don't see why you can't build your own structure into your REST solution.

EDIT: When I did telecom programming our phone switch only supported SOAP and not REST. I found that SOAP required a bunch of boilerplate stuff that just got in my way when I didn't need it.