Is it all about security?
Imagine that you’ve spent a great time in the restaurant enjoying your meal and chat with friends. But the most interesting moment of our short story starts when it comes to paying. Imagine that your debit card is the message you want to share. You can give it to the waiter, let him go away with your card, and hope he’s not going to copy all the data from your card and steal your money - that is the HTTP. You can also go with him or pay at your table and make sure he doesn’t see all the sensitive data - that’s the HTTPS. And you have the third option - you can go with the waiter and additionally stick a black tape to the card and hide all the data you don’t want others to see - and that’s the WS-Security.
I know that it may not sound clear yet, but I promise the idea will crystalize through the whole article. My point was to show you that there are different approaches to message encoding, and that has an enormous impact on data security. Some industries need to take exceptional care about the users’ security, and that’s why they prefer to choose additional protection features. And that, of course, influences the choice of the specific types of API. I think the approach to security is one of the main differences between REST and SOAP API, especially when we take a look at the use cases. Of course, it doesn't mean that one solution is safe and the other not. It's rather choosing between a safe one and the safer. There is much more to say about these types of API and here I’m going to take a closer look at each of them.
Want to know more about APIs? Subscribe to our Youtube channel and watch our “Let’s talk about APIs” series!
What is REST API?
You’ve probably encountered this name many times, and plausibly, this kind of API is much more approaching to you. And it’s not surprising as REST API has conquered the market in recent years, and now we can say that around 70% of all APIs used in the web is REST API. But let’s try to figure out what REST API exactly is and what has influenced its rising popularity.
REST stands for Representational State Transfer. It’s an architectural pattern that was designed to benefit from existing protocols, like HTTP or HTTPS. It supports various data formats like XML, JSON, HTML or plain.text. And that’s one of the main reasons for its most common usage, as implemented with JSON is able to bring more benefits for your project - it’s actually one of the best practices you should consider when working with REST API pointed out by Maciej.
It’s commonly believed that REST API is a new solution, but in fact, it’s a popular misunderstanding, probably its growing popularity in recent years helped to spread it. REST was conceptualized in 2000, so it is only two years younger than SOAP! Although REST has been almost 20 years with us, it is still not standardized, which can make some business owners opt for SOAP. But on the other hand, the lack of strict rules of implementation leaves room for designing it strictly to your needs, what can be (and certainly is) appreciated by many product owners.
Even though it doesn’t impose any rules, there are six main architectural constraints that can define the RESTful API. It would take a lot of time to describe all of them, but let’s focus on some that can be important when comparing with SOAP. Statelessness is something that we should definitely point out here. When we talk about stateless communication, we mean that the message you send contains enough information, so there is no need to bother the server with that data. Thanks to this solution, the REST API is lighter than SOAP and works much faster. Another thing that helps avoid an additional load of the server and reduces the load time is caching. It’s a way of improving your web scalability and performance and with REST API it’s really simple to implement that.
So as you’ve probably figured out, in my example at the beginning REST API was mentioned in HTTP and HTTPS cases, so in the second example - your data is safe and this level of security is sufficient for many enterprises and startuppers. But what if you needed an additional way of protecting sensitive data? Well. that’s where the SOAP API comes into play.
What is SOAP API?
Let’s start from the very beginning. SOAP stands for Simple Objects Access Protocol, so even at this step, we can distinguish the first difference between SOAP and REST. As it’s clearly explained in the name, SOAP is a protocol, while REST is an architecture pattern that operates on protocols like HTTP and HTTPS. Unlike REST, SOAP is highly standardized, which has a significant influence on its approach to data security.
Lots of industries still appreciate the possibility of implementation of WS-Security in SOAP - and that’s the third case mentioned in the example at the beginning of this article. Actually this example was firstly made by Vittorio Bertocci from Microsoft, who used the metaphor of… naked motorcyclist. Ok, but the HTTPS data is already encrypted, why would we need to add another level of protection? Industries like finance or healthcare are obligated to take special care of user’s data and that’s why they should decide on encrypting the data also on the message level, and WS-Security gives that opportunity.
But everything has its price. SOAP ensures better protection but that makes it a much heavier solution and it influences the performance. What also slows down projects with SOAP API is the fact that this kind of API is stateful - unlike in the case of REST, in this case, the server keeps all the information received from the client across various requests. But there is also the other side of the coin - this approach to state is useful for flight or hotel booking systems that can display variable information in multiple steps, based od the saved data.
On the other hand, offering a highly standardized solution means a lack of flexibility in the API implementation, which can lengthen the whole process. Another significant difference between REST and SOAP API is a data format. Unlike REST, SOAP supports only XML which is much more tedious than JSON. It would be also more difficult to implement caching, as SOAP requires a dedicated cache module.
REST vs. SOAP API - what should you choose?
If you’ve read the whole article you probably expect to get an answer (you requested an answer, to stick the API terminology) - should you choose REST or SOAP API? I don’t want to leat you down but I can provide you only with one response that everybody hates - it depends. Choosing the right API is a tough decision and you need to know the answer for some basic questions first - what’s the goal of your project, who is the user of your app, do you work with sensitive data, etc.? For some startups that need to quickly enter the market to attract investors’ attention, deciding on REST would be a faster solution. Using SOAP means more time spent on studying API documentation to act according to the protocol. On the other hand, it provides better security solutions. It all depends. But it depends on you, so prepare yourself for this decision and choose wisely.