Memories from a 2-year SOA adventure, episode 1 : Soap versus Rest

Memories from a 2-year SOA adventure, Episode 1 : SOAP versus REST

After spending almost 2 years working in an important French retail company where I helped teams to adopt a Service-Oriented design and development approach, time has come for me to assess what I’ve learned.The purpose of this series of blog posts is to share some experience, mostly coming from in-field discussions with software architects, vendors and integrators at my customer’s premises. This first article is dedicated to a very well-known but still very popular debate: should you rather do SOAP or REST web services?

Several months ago, my customer’s head-of-architecture finally realized that SOA was spreading fast in his organization, that having teams doing different choices of implementation was costly, and that he had to provide some common guidelines in order to ensure people were producing and understanding (web) services the same way. Amongst other propositions, an internal urbanization committee assessed the eventuality of producing only REST-like web services. I was asked to help the committee to review (and validate) their analysis of the situation.

It appeared that this committee had a strong preference for RESTful web services. Their conclusions were based on a study of an in-house tech lead, who had done various investigations, interviews of team-mates, and researches on the Internet. Basically, the slides were telling that:

  • “REST is easier to understand, than SOAP”; consequently, “training is faster and cheaper”;
  • “REST is simpler to develop and to maintain, than SOAP”;
  • “REST is more lightweight, than SOAP”;
  • “REST is less standardized and therefore more flexible, than SOAP”;
  • “REST is more suited for mobile-oriented development, than SOAP”.

All kind of internal and external figures were then shown to demonstrate that REST is becoming more and more popular than SOAP, including a Google Trend chart and famous charts from ProgrammableWeb. So the bottom line of the presentation was that the customer’s software teams should now develop only RESTful web services, because it’s less costly for the organization and far more sexy for developers.

I cannot say that I were surprised by these conclusions. The myth of REST being “simpler” to develop than SOAP is widely spread in the minds of many developers. Thing is, many developers tend to make a confusion between the simplicity of the architecture and the productivity of the approach.

Truth is, if you look at the number of lines of code required to produce a SOAP web service using JAX-WS, and the number of lines required to produce a REST web service using JAX-RS, you will roughly get the same figures. On the other hand, the effort to develop a consumer is not the same depending on the approach. In the case of SOAP, client skeletons are usually generated from WSDL service contracts, which is usually a matter of seconds. In the case of REST… well, while there are ways to do contract-based generation the same way as SOAP (I shall come back to that in another post), this is not a straight-forward decision.

Thus, as a software team, if you want to start the implementation of your APIs quickly, using REST-like services is not necessarily the best approach, as you will first have to spend some time:

  • Choosing the format of your envelopes : XML, JSON (all-time favorite), other;
  • Choosing the format of your URLs and how you manage non-CRUD actions;
  • Choosing how to document, expose and share your API;
  • Choosing how much metadata you want to expose with your services;
  • Learning and debating about HATEOAS and other polemical REST-specific concepts.

You may find yourself more productive with REST, but depending on the needs, I would still advise some teams to go for the standardized XML-based and WSDL-documented SOAP approach; especially if there is a need for an urgent release, and/or in a multi-team and/or a multi-technology environment. Furthermore, some would say that REST is only suited for resource-oriented APIs, although I tend to see REST as a set of principles which make sense in most cases.

In the end, my feedback for my customer was: you sure can go for a full REST-based web service strategy, and you probably will be more future-proof, in particular for mobile clients, but please first put some effort in standardizing the way your organization wants to design and develop RESTful services. Currently, there are as many ways to do REST as there are software teams to do it. And some ways are much more costly than the “deprecated” SOAP way.

Share
Alexandre ESTELA

1908

Comments

  1. Thomas Zayouna Says: January 13, 2015 at 8:20 am

    Tools such as CXF can be really helpfull in this kind of case, exposing REST and/or SOAP. CXF even has a OAUTH 2 server implementation available

    • Alexandre Estela Says: January 13, 2015 at 10:19 am

      Indeed, CXF handily shows a list of all SOAP/REST services with links to the related WSDL/WADL contracts, which provides an API management strategy for both approaches.

  2. Nabil GAMMOUDI Says: February 21, 2015 at 8:58 pm

    I have some critics :
    1- Comparing SOAP and REST is unfair : SOAP is supposed to be a protocol whereas REST is an architecture.
    2- There are more and more interest on REST, there are serious API dealing with REST design. You can see RAML, it’s a wonderful API ! Two mature teams do the same design.
    3- Architectural choices are not done by counting lines of a program ! It’s possibly a google inspiration : https://developers.google.com/soap-search/?csw=1.

    • Alexandre Estela Says: February 23, 2015 at 11:21 am

      Thanks for your interesting critics ! Hereafter some answers :
      1 – You’re right, strictly speaking, SOAP is a turnkey standard while REST is an architecture (or a “set of principles”, as mentioned in the article). However many of our customers have this very simplified vision opposing “SOAP services” to “REST services” ; so I used that same perspective in order to make my points as clear and understandable as possible for their debate.
      2 – You’re right also to mention the growing interest on REST ; however RAML is not an API standard, or better said, it is just one of the many “industry standards” you can choose to share RESTful services 🙂 along with Swagger, Apiary, WADL, etc. So I don’t agree with the “Two mature teams do the same design” statement : with all the possible API design/documentation approaches out there, how can you ensure that these two teams will converge, without prior negociation (which is not necessary with a SOAP approach) ?
      3 – Regarding line counting, I was pointing the fact that REST-based development does not require less code-typing than SOAP-based… as I am often told the contrary in technical interviews 😉

Leave a Reply

Your email address will not be published. Required fields are marked *