From SOAP to REST: web service evolution and hidden pitfalls

XML Web services brought a breeze of fresh air in the way B2B interactions happen in today’s digital world. Logistics, transportation, invoicing and other retail sectors were revolutionized, since real-time updates for everything were now possible. For example checking the availability of multiple products, ordering and paying for them, is now possible in an automated way with minimal/none human intervention.

One of the big barriers to full web service integration is usually the different architecture of the systems involved (especially legacy systems). XML is the lingua franca of the internet, but sending and receiving XML messages was handled in different ways. To address this unification challenge, SOAP (Simple Object Access) protocol was suggested along with its complementary suite of WS-* services (WS-Addressing, WS-Discovery, WS-Federation, WS-Policy, etc.)

SOAP is mature and well tested, but sometimes it is too complicated to implement and embed in an existing application. Not all systems require such level of security and flexibility. Several systems took the alternative road of using JSON and REST (Representational State Transfer) services. The REST solution is considered much more lightweight than SOAP which enticed several vendors and integrators to either offer REST along with SOAP capabilities or even switch exclusively to REST.

But even the REST architecture suffers from several shortcomings. The major one is the lack of a formal specification. The original REST dissertation is the PHD thesis of Roy Fielding, and that was published in 2000. It has been 15 years since that time, and there are still discussions on what REST entails, what it requires and what it forbids. Best practices come and go in the blink of an eye and restful architectures are always discussed in a passionate manner.

The DevIT conference (May 15th Thessaloniki – Greece)

To explain better the shortcomings of REST and how they affect the implementation of a web service, Trasys will present in DevIT (http://devitconf.org/) the common REST problems and misunderstandings. DevIT is a new conference located in northern Greece. It attempts to cover multiple IT topics related to web development, deployment, management and implementation of IT systems.

The presentation has two parts. The first part is mostly theory and addresses:

• Some history on HTTP and REST
• The relationship of HTTP and REST
• Common pitfalls with REST.

The second part delves into practice and explores a common issue with the design or REST systems – the error reporting. There are several approaches on this topic. We will explore the usual approach where HTTP error codes are used, the custom solution where the error is embedded in the response and the hybrid solution that attempts to combine the two.

In Trasys we are already employing both SOAP and REST architectures in our solutions, so we base our recommendations in extensive real-world experience.