3

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

Community
  • 1
  • 1
Damien Overeem
  • 4,487
  • 4
  • 36
  • 55

1 Answers1

28

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:

  • REST is much simpler, basically just building on top of HTTP
  • You can test (and debug) REST services using a web browser or something like curl or httpie. Yes this is technically possible with SOAP as well, but you have to somewhat understand the SOAP schema.
  • Similarly, you can build a REST client as long as you have a way to access HTTP. SOAP requires a SOAP-capable library
  • REST is more of a style and builds on top of HTTP, whereas SOAP is an entire protocol on top of HTTP (which is also a protocol)
  • SOAP ends up with crazy extension protocols like WS-Security, WS-Encryption (which, essentially, are incredibly complex designed-by-committee solutions to problems the rest of the internet solved for HTTP a couple decades ago)

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.

gregmac
  • 24,276
  • 10
  • 87
  • 118
  • 1
    Thank you. You gave me exactly the type of answer I am looking for. Comparing technical differences never really explains the -why- behind someones choice (most of the time). I will leave the question unanswered for the time being because I would like to hear more oppinions from people who made the choice before me, but in any case +1 for your effort! – Damien Overeem Dec 13 '12 at 08:15
  • But REST does not support Transaction and Message reliability (delivered or not) and Message security – RN Kushwaha Apr 01 '15 at 06:52
  • One other big advantage I see on SOAP is the fact that you can use standardClasses to send over the API. Which has the advantage that you don't need to parse json, but can send classes/objects over the API, thus having no media break but keeping everything object oriented. – Canelo Digital Mar 08 '18 at 13:49