( Not a duplicate of Should i use rest or soap. That question has only 1 answer which doesnt provide many arguments except overhead ).
Before marking this question as a duplicate, consider that I am looking for answers from people that made the choice before me and that explain their reasons based on their own experience. Answers that simply state “overhead” or “more complex” do not fit that profile.
Now for the question:
A while back I’ve started to setup a new api using Soap (PHP / Zend_Soap_Server, Zend_Soap_Autodiscover). Although I’ve figured out how to work with soap, the complexity makes me wonder if this is a good choice for future maintenance.
I’ve heard about REST, but do not have any experience with it.
So the question is: what are the pro/cons of REST vs SOAP and what is your suggestion when creating a fresh new api (rather complex api, several dozens of methods, using ssl, must have decent security etc), REST or SOAP.
If you think your answer hangs in the balance between REST and SOAP and a specific dependency or feature would tip the scale, be sure to ask whatever you need to know. I’ll answer as soon as I can.
A short list of the api’s features:
- Authentication
- Perform math functions for a frontend
- Provide binary files to the frontend (invoices)
- Basic CRUD of various sorts of information
The place of the api is basically as follows:
Internet -> website -> [internal network] -> API/Backend -> Database
Thank you for your time in advance..
This is of course a very controversial topic, but at the same time, most new services are REST for a number of reasons. I won’t cover the differences between the two (as that is well documented) but more the reasons I think you’d build a new service, today (2012) using REST:
If you look around at some of the major APIs on the internet (eg Google, Facebook, Twitter, etc) you’ll find a lot of REST, and little to no SOAP. Those that do have SOAP interfaces are deprecating or dropping them completely, because there’s very little reason to stick with it any more.
In fact, many of the big services are going a step further and only offering their REST services with JSON formatting, as opposed to XML or both, because like REST over SOAP, JSON has a lot of advantages in terms of size and simplicity over XML that it doesn’t make much sense to continue supporting XML.
There are also almost no drawbacks to REST compared to SOAP.
About the only practical consideration I can think of is from a client perspective. With SOAP (because of WSDL, assuming you produce one) you can point a SOAP-capable IDE at the service (such as VisualStudio) and it will generate a native client proxy API based on the remote service. This is somewhat nice in terms of getting up and running quickly, but has its own set of drawbacks: it forces you to use the objects defined in the service (whereas with REST, you can use your own object definitions as long as the data maps in), and depending on how the remote service handles versioning (or not) and how you use it, you may end up having to update major chunks of your app because of something as simple as a naming change.
From the server perspective, I really can’t see any technical benefits to choosing SOAP over REST whatsoever.
TL;DR: SOAP is not necessarily bad, it’s just that REST is better.