Do you use the SOAP protocol as part of your API interface programming? This article is a quick guide to the history and specifics of SOAP.
What does SOAP stand for?
Simple Object Access Protocol. The protocol was developed to add structure to web service communication while maintaining extensibility and remaining operating system agnostic. In essence, it helped turned the Wild West of data communication into a set of structured formats.
When was SOAP created?
This protocol was first developed by a team at Microsoft in 1998 and the specification was later published to the Internet Engineering Task Force (IETF) in 1999. It was a direct successor to XML-RPC (remote procedure call) and aimed to standardize the communication between web services.
Extensible Markup Language (XML)
The SOAP protocol uses the Extensible Markup Language, for better or for worse, to format its data. This markup language allows developers to have a strongly typed format while still being able to customize the nodes to fit their needs. This extensible language can be tailored to any given web service, but it comes at the cost of being too verbose. The start and end tags add large amounts of overhead to the size of the SOAP request and the string parsing of the XML itself is fairly slow. More modern paradigms such as REST have moved to lighter weight formatting to cut down on the parsing time and message size.
Pros of SOAP
Extensible – The XML markup allows developers the freedom to add their own fields as long as they stay within the bounds of XML tags
Flexible transport – SOAP is transport-agnostic and only relies on the SOAP envelope information to make it from the source to the destination. This could be done over various transport methods such as HTTP, TCP/UDP, or even SMTP.
Rigid schema – This aspect is a double edged sword. The rigid schema allowed for well formatted and structured data but at the expense of scaling.
Cons of SOAP
Large – The formatting of the data is bulky
Slow – Parsing XML tags is a slow process
Client support – SOAP clients are language specific and have to be developed within each respective language
Scaling/versioning – Client and server have to be changed at the same time in order to maintain a working protocol
SOAP in the modern era?
While Service Objects still supports SOAP, the protocol may be nearing its end of life. Adoption of the protocol has slowed and modern development has been moving towards the RESTful paradigm. SOAP helped pave the way for structured communication between web services, and aspects of its design have been carried forward into the protocols of today.
