What is the difference between SOAP and REST? That’s not a quick question to answer. REST vs SOAP API use is a long-debated topic. Both have their advantages, as well as their disadvantages. We’ll dive into the detail of these below, looking at when to use SOAP and REST web services in order to achieve the security, flexibility and developer-friendliness you need.
What is SOAP?
Simple Object Access Protocol (SOAP) is a communication protocol that is known for being secure, reliable and heavily standardised. Microsoft originally developed it as a client-server protocol for web communications in the late 1990s. SOAP is now used around the world, enabling a vast range of modern systems to communicate with one another.
One of the key reasons for SOAP’s widespread adoption was its ability to enable easy communication and data exchange between different programs built on different platforms using different languages. It’s fair to say that SOAP was something of a game-changer, back in the day. Adopted as a web standard, it became widely used around the globe.
On a technical level, it was SOAP’s use of XML for providing messaging services that was such an advancement over previous, binary-based messaging protocols. As the internet era got firmly underway, SOAP was able to deliver where these previous protocols could not.
With its standardization courtesy of the Internet Engineering Taskforce, SOAP became highly extensible, with users able to fulfil all kinds of use cases courtesy of WS-Addressing, WS-AtomicTransaction, WS-Coordination, WS-Federation, WS-Policy, WS-ReliableMessaging, WS-RemotePortlets and WS-Security. Users can pick and choose the elements they need for their particular use case.
Features of SOAP
A SOAP-based API can enable clients to create, retrieve, update and delete records from a server, following pre-defined rules. Those records could include anything from passwords and accounts to custom objects. SOAP easily facilitates this, enabling communication between different software and systems.
SOAP can support both stateful and stateless operations, again meaning that it suits a range of use cases. SOAP APIs are stateless by default but developers can make them stateful if required.
Another key feature of SOAP is its enterprise-level security, courtesy of WS-Security and SSL support. We’ll explore this in more detail below.
Built-in error handling is a super helpful SOAP feature. When things go wrong, the faster you know why, the faster you can fix them. With SOAP error responses using standardized codes, problem identification can take place more rapidly and more efficiently.
SOAP APIs work on a range of transfer protocols, including HTTP, SMTP, UDP and more.
Challenges in SOAP API use
SOAP APIs are not without their challenges. Some of these are broad, while others are more specific. At a high level, SOAP’s pre-defined rules and structures mean that implementing it doesn’t always involve the flexibility you might need.
Using SOAP for mobile applications and microservices architectures, for example, is unlikely to end well. There’s a good reason that discussions around microservice gateway and access patterns usually involve a mention of REST (or more recently GraphQL) instead of SOAP. While SOAP certainly delivers in terms of security, it is less well suited to lightweight, flexible use cases such as these.
More specific challenges can depend on things like which programming language you’re using. SOAP’s use of XML can pose problems when it comes to building requests in certain languages, largely due to SOAP’s intolerance of errors, which can make creating requests and parsing responses rather onerous.
That said, if you’re using .NET languages and various other languages, a range of shortcuts and the use of Web Services Description Language (WSDL) can actually make things easier. However, that WSDL file is a double-edged sword. Change the file, for example, and all clients who are connecting to your web service will need to update their code.
The final challenge with SOAP relates to bandwidth. XML messages can be large, which can impact bandwidth requirements noticeably. All the additional WS-* bloat certainly doesn’t help either. If bandwidth is a priority when you’re weighing up SOAP and REST, SOAP is unlikely to win.
SOAP API example
There are plenty of examples of SOAP APIs out there to play with, if you’re seeking to understand the features, opportunities and challenges of SOAP for yourself. Postman provides numerous examples of public SOAP APIs that you can use to do so.
What is REST?
Representational State Transfer (REST) is an architectural style that has been adopted around the world. Computer scientist Roy Fielding created REST, first presenting the idea in his 2000 PhD thesis, after years of working at the World Wide Web Consortium (Fielding is also known for co-authoring the HTTP 1.0 specification).
Fielding didn’t mention REST APIs – also known as RESTful APIs – when he presented REST in his thesis. That’s because REST is the architectural style that has guided the design of modern web architecture since around 1994. REST APIs came later, following the REST guidelines to enable the easy transfer of data between different systems.
A fundamental difference of SOAP services vs REST services is that REST isn’t limited to the use of XML. While you can use XML with REST APIs, it is more common to use JSON. All REST needs is simple URLs, rather than the creation of complex requests. It also requires the use of HTTP or HTTPS.
REST’s ability to work well with JSON, which is supported by nearly all modern programming and scripting languages, has supported its widespread use on a global scale.
Features of REST
REST is a lightweight architecture that is ideal for minimising bandwidth requirements. The fact that it is highly scalable and flexible means that it is well suited for many modern use cases, from mobile apps to microservices environments.
RESTful API guidelines ensure that APIs are stateless, cacheable and layered through separation of concerns, as well as featuring client-server separation and a uniform interface with common formatting for standardised communication. Code on demand is also a feature of many REST APIs, though this is an optional characteristic rather than a requirement.
REST uses four commands to carry out tasks: GET, POST, PUT and DELETE. Data can be output in a range of formats, including CSV, JSON and RSS, meaning that developers can obtain the data they need in the format they need.
Challenges in REST API use
One of the key challenges with using REST for APIs used to be its lack of baked in security. Messages are secured only when in transit using an HTTPS connection, unless security mechanisms (such as authorisation and authentication) are implemented as part of the API’s design. This is why REST was initially often the architectural style of choice for public APIs for web services, rather than more sensitive use cases, where SOAP was the preferred choice.
However, modern REST APIs make use of a range of security features provided by API Gateways to overcome this challenge. These include open standards based authN/authZ using (m)TLS, api keys, password hashes, OAuth 2.0/OIDC, as well as input parameter validation and IP whitelisting, REST security is now robust enough to stand up to use in open banking and other use cases involving sensitive data.
REST API example
Examples of public REST APIs are available on Postman for those who want to play around with them and grow their knowledge of REST first-hand. There’s also plenty of scope to discover how easy it is to create REST APIs and to manage them securely when you use Tyk’s open source API gateway.
The key differences between SOAP and REST
There are multiple fundamental differences between SOAP and REST. If your concern is the difference between REST and SOAP in terms of APIs, some of the key differentiators include:
- Robust messaging protocol – SOAP provides a more robust messaging protocol than REST, with built-in error handling and security, as well as transaction support. If security is a key concern, remember though that this is one of the top benefits of Tyk when managing both SOAP and RESTful APIs (and all other APIs).
- Bandwidth – REST is more lightweight thanks to its use of JSON (typically) and its smaller message sizes, while SOAP is more heavyweight due to its use of XML and larger messages.
- Flexibility – when it comes to a SOAP vs REST web service decision, REST will win the day if flexibility is your priority, thanks to its less rigid rules.
- Caching – it is easy to cache REST API calls. However, SOAP is not cacheable when using the HTTP transfer protocol.
- Simplicity – REST is simple, SOAP is less so. This means there is a smaller learning curve when it comes to using REST.
Deciding between SOAP and REST
What is it that is most important to you when building an API? Understanding this will feed into your decision as to whether to use SOAP or REST.
If you’re in need of enhanced security, transaction support and built-in error handling, and happy with fixed rules and standardisation, for example, then it’s likely that SOAP will suit you best. However, if you need greater flexibility and reduced demand for bandwidth, then REST might better meet your needs.
It’s worth noting at this point that the decisions you make in terms of SOAP and REST APIs don’t need to be with you forever more. Business needs can change significantly, which is why Tyk has made it easy to transform your API traffic to and from both SOAP and REST (as well as XML and GraphQL). You can do all of this behind the scenes while serving up a single, unified point of entry to your API consumers. This is one of the many benefits of using Tyk as part of your API management architectural and deployment patterns. You can enjoy the flexibility to need to grow, evolve and scale your business even as your needs – and those of your customers – also continue to grow and flex.
When to use SOAP
If you’re looking for standardisation, automation for certain programming or scripting languages, transaction support, security and built-in error handling, it could be time to use SOAP. SOAP APIs are, of course, also the natural choice when integrating with SOAP legacy systems.
One key SOAP and REST difference is that SOAP is transport independent, so if you don’t want to use HTTP, then again it’s likely that SOAP will be the best choice to meet your needs.
Generally speaking – though use cases differ massively! – if you have a distributed enterprise environment and are working with sensitive data, then it’s probably time to embrace the SOAP protocol. Although REST has certainly done it’s best to replace SOAP over the past decade or two, SOAP still has it’s place. Albeit a place that is diminishing in size!
When to use REST
If it’s a more lightweight solution that you need, for example for a mobile app or microservices architecture, then it’s time for REST – along with a highly performant microservices API gateway, of course.
The reduced bandwidth that comes with a RESTful architecture can certainly pay off, thanks to REST’s greater efficiency in terms of message format and size when compared to SOAP. The greater range of choice in terms of message format also makes REST an ideal option if you value flexibility.
One other REST and SOAP API difference that is worth considering is the smaller learning curve that comes with REST. This generally means that you can get to grips with your API project faster and potentially therefore get to market faster. You may also need to expend less resource when using REST, again thanks to its comparative simplicity.
Ultimately, both SOAP and REST have distinct advantages and disadvantages. Understanding the differences between the two puts you in a stronger position to decide which will best suit your business’ particular use case. Of course, this debate doesn’t even touch on whether the use of GraphQL might be the right choice for your organisation… but we’ll leave that conversation for a whole other day!
In the meantime, if you’ve got any questions about the whole REST vs SOAP API debate, all you need to do is reach out to the friendly Tyk team.
