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.