Introduction

This article discusses two web service access protocols, SOAP (“Simple Object Access Protocol”) and REST (“Representational State Transfer”).

Web Services

Web services are defined to actively fetch, read, or transfer data from a defined source to produce a specified outcome – a result.

The following rudimentary example shows a basic use of web services before understanding how the data is transferred to and from the web service, using SOAP or REST.

If a developer is writing an application that requires some data calculation in one place, the will write the calculation method in the code, in that one place.  However, if the data calculation is needed in other parts of the application, it would be inefficient and impractical to maintain if the developer placed the calculation method in every area it is needed.

Having to make one change to that method would require finding every instance to edit (and retest).   This scenario would benefit from using a web service to function optimally and improve business agility.

By creating one web service with accessible methods to add, subtract, divide and multiply, the application will engage with that web service whenever data calculation is required; it calls the web service to do the calculation and produce the result.  So there is only one place for the developer to maintain the data calculation method.

The way data is handled in web services is determined by whether SOAP or REST is implemented.

SOA and BPMN

An application built on executable processes is based on a Service Oriented Architecture (“SOA”).  It is an approach on how to use services that transfers, produces, validates or calculates data.

SOA is becoming more and more favourable to improve on development quality and time, and improve application performance and scalability.

Business Process Modelling Notation (“BPMN”) is modelling a service or business process, which can be done by non-technical people i.e. the business analyst.  Using BPMN, business models (for services) are easily interpreted by developers who implement the model as an executable process, and these processes may or may not require human interaction.

Simple Object Access Protocol (SOAP)

SOAP is a method of transferring data over the internet.

Originally developed by Microsoft due to the advent of the internet, SOAP replaced the old DCOM and CORBA technologies, and it has been around for a lot longer than REST.

SOAP is regarded as heavier than REST i.e. there is more baggage required to transfer data, which means more bandwidth is needed per message request and the data source and targets have more work to do when packaging and receiving the data.

SOAP only uses XML for messaging services over the internet, and XML message requests can be very complex and if developed manually, careful attention is required because SOAP is inflexible with errors.

It is possible to automate SOAP message requests using .NET languages (as an example), where developers do not need to work with the XML as it is generated automatically in the background.

If any problems are encountered with the message request, detailed error information is returned in the message response, and this process can also be automated by referencing the standard error codes provided in the message response.

Therefore, the programming language used is a determining factor in how difficult it will be to implement SOAP.

One of the pieces of baggage that accompanies a SOAP message is the Web Services Description Language (“WSDL”) to explain how the web service works.  When an application references the web service, it reads and understands what to do with the web service.

SOAP is not bound to using HTTP (HyperText Transfer Protocol) exclusively; it can be used over SMTP, and other transport protocols.

As SOAP was standardized, it is more rigid than REST, although both do depend on established rules.

REST

REST is the newer and more sleek cousin of SOAP, and fast becoming the choice for most web and mobile applications.

More than a decade after its introduction, REST is a lighter, more maintainable and scalable way of interacting with web services.

Unlike SOAP, REST does not use XML exclusively; plain text, CSV, and RSS can be used, as well as JSON for AJAX calls; as long as both the source and targets can understand the formats used.

REST is less complex and considered a smaller learning curve than compared with SOAP.  Most modern programming languages have libraries and frameworks to facilitate REST (RESTful) services, such as C#, Python, Java, and Perl.

REST is faster due to minimal processing and being more efficient using different message formats.

There are advantages and disadvantages to both, so when considering which access protocol to use, consider the programming languages used in the organization, the application environment and application requirements.

Sharing is caring!