SOAP vs. REST APIs: Mobilize Your SOAP Services With RESTful APIs

What's the difference between SOAP and REST APIs? In this blog, we break down key differences between SOAP vs. REST APIs. And we explore a proven approach to extending SOAP services for mobile app consumption with RESTful interfaces.

What's the Difference Between SOAP and REST APIs?

Mobile apps frequently use the Representational State Transfer (REST) protocol to interact with other systems while corporate infrastructure commonly uses Simple Object Access Protocol (SOAP) and other XML-based models.

RESTful APIs are key in the new mobile app economy. But few enterprise systems are configured to support RESTful apps. While SOAP was excellent for many aspects of the service-oriented architecture (SOA), it is too complicated and bulky for use with mobile apps — or today's microservices. As a result, provisioning back end system access to mobile apps can be challenging.

Securing the Edge API and Microservices Mesh

APIs and microservices both offer points of vulnerability. Learn how to secure the edge API and microservices mesh in this in-depth white paper.

📕 GET THE WHITE PAPER

Enterprise Applications vs. Mobile Apps

Corporate apps need to connect with backend systems. For example, in the leading corporate app category of business intelligence (BI), apps have to be able to request data from enterprise data stores. This presents a problem in most cases. The mobile app is designed to interact with other systems using the REST protocol and JavaScript Object Notation (JSON).

Enterprise systems often use one of several dominant modes of enterprise messaging, such as Message-oriented-Middleware (MOM), Java Messaging Service (JMS), or SOAP, a form of XML that has become popular in recent years. REST and SOAP don’t interact naturally.

SOAP vs. REST: Historical Context

The SOAP-REST disconnect is ironic. Years ago, service-oriented architecture (SOA) was billed as a revolutionary advance in interoperability. It promised to enable simple data exchange and procedure calls between any software, regardless of network. SOAP is thriving in the enterprise.

However, mobile app developers prefer not to use it. Despite its versatility, SOAP can be more difficult to program than REST/JSON formats. And, SOAP uses more processing power. So it’s not well-aligned with simple mobile device processor chips or limited batteries.

For the purpose of solving the SOAP-REST disconnect, it’s helpful to understand the history of the two protocols and the problems they were designed to solve.

SOAP and related standards, such as Web Services Description Language (WSDL), were developed in the 1990s to provide a better way for distributed systems to share data and procedure calls. Virtually all major technology vendors adopted SOAP and WSDL as open standards ushering in a revolution of interoperability.

This enabled enterprise architects to build service-oriented architectures where software applications could be exposed as standards-based web services. This made them accessible to any other application using SOAP.

REST is newer. The concept was introduced in 2000 by Roy Fielding, the computer scientist who has influenced the development of many World Wide Web standards. REST was a core architectural principle for the web. However, REST has recently gained traction as an alternative to WS and SOAP-based services. This includes consumption within mobile devices, the Internet of Things, and many open customer-facing web properties.

SOAP vs. REST API: Pros and Cons

SOAP and REST serve similar purposes in their architectural design. Both allow software applications to call on web services to retrieve data or make procedure calls. Yet, it’s a bit like comparing a helicopter and an airplane. They both fly through the air, but in different ways.

SOAP and REST each have their advantages and drawbacks, including:

• SOAP is a protocol that uses Extensible Markup Language (XML) to transmit messages over a variety of transport protocols, including HTTP, TCP, IBM MQ (MOM), FTP, Java Message Service, and others.
• On the other hand, SOAP web services capabilities were built into most major software development tools, including Microsoft Visual Studio .NET and IBM Rational DeveloperWorks.
• The consensus is that SOAP is easy to integrate while also accounting for security, policy management, message routing, and so forth. Obviously, this makes SOAP enterprise-friendly. Figure 1 (below) shows this enterprise-to-enterprise (E2E) approach to architecture.

An Example Rest API

So how does this work, exactly?

REST runs on top of the HTTP transport. It takes advantage of HTTP’s native capabilities, such as GET, PUT, POST and DELETE. When a request is sent to a RESTful API, the response returns in either the JSON, XML or HTML format.

A RESTful API is defined by a web address, or Uniform Resource Identifier (URI), which typically follows a naming convention.

Let’s explore a hypothetical situation to clarify further.

1. Imagine that mysoles.com, a fictional online shoe store, wanted to allow a mobile app to have access to its product catalogue database. It could create a RESTful API with a URL of http://api.mysoles.com/catalogue.
2. The mobile app developer could pull the catalogue onto the app by writing an HTTP request of “GET” to this URL.
3. To get a specific item from the catalogue, the developer would write “GET” to a version of the api that contained the product number, such as http://api.mysoles.com/catalogue/[sku]. When the RESTful API received the HTTP request, it would return the product information in JSON or some other web standard format.

Figure 2 (below) captures this basic B2M architecture.

If mysoles.com made its catalogue database available as a SOAP web service, the app developer would need to download the WSDL and learn how to code a SOAP request specifically for the shoe catalogue. If the SOAP web service were located at http://ws.mysoles.com, the SOAP request would look something like this:

<soap:Envelope xmlns:soap=”http://www.w3.org/2001/12/soap-envelope” soap:encodingStyle=”http://www.w3.org/2001/12/soap- encoding”>
<soap:Body xmlns:m=”http://ws.mysoles.com”>

<m:GetSKU>

    <m:SKU>Jimmy Choo</m:SKU>

  </m: GetSKU>

</soap:Body>

</soap:Envelope>

In order to write this request, the developer has to know the name of the variable (SKU) and how to format the request so it will return the right information.

So fundamentally, REST involves a lot less coding to accomplish the goal of accessing an information resource or requesting a procedure. These qualities make REST a great deal simpler to work with than SOAP, though they present their own limitations.

SOAP Advantages

SOAP offers several advantages over REST in an enterprise context including:

• Independence of language, platform and transport. (In contrast, REST requires HTTP).
• Works well in distributed environments, such as the enterprise. (REST assumes point-to-point).
• Well-standardized after more than a decade of serious enterprise use.
• Pre-build extensibility with WS* standards.
• Built-in error handling.
• Automation when used with certain languages.

REST API Advantages

Yet REST is easier and more flexible in the following ways:

• No expensive tools needed for interaction with web services.
• Shorter learning curve.
• More efficient (XML, used in SOAP messages, is longer than REST’s message formats).
• Faster, with less processing required.

Does REST Matter?

Given REST’s distinct suitability for the web, it is no surprise that app developers prefer REST to SOAP.

SOAP, with its maturity and extensibility, is a natural fit in the enterprise. But when it comes to figuring out how best to expose enterprise systems to mobile apps, does it really matter? If enterprises wish to remain competitive, the answer is a resounding yes.

Mobile app developers use REST. This most certainly will not change. And enterprise applications are increasingly exposed via RESTful APIs. Yet, many are still based on the SOAP protocol. For those still using SOAP, they must find a way to connect the dots.

How to Mobilize Your SOAP Services With RESTful APIs

There is every reason to be optimistic that the gap can be spanned between SOAP-based web services and the surging wave of corporate apps. The secret is to let everything be. It’s okay to allow SOAP to remain the application integration powerhouse in the enterprise. Let REST be the dominant mode of interaction in the mobile app world.

The most viable approach to connecting mobile apps with enterprise back end systems is to transform existing SOAP web service into a RESTful API. This way, the SOAP service can stay in place, whereas the mobile app can easily access the data and procedures it needs.

Figure 3 (below) shows an enterprise-to-mobile (E2M) approach to transforming SOAP web services as RESTful APIs. In this example, developers (on the left of the below figure) would create RESTful APIs for each web service they wanted to make available to mobile apps.

The app calls on the RESTful API using an HTTP request, as is the norm for REST. Using Akana’s API gateway, the RESTful API transforms the HTTP request into a SOAP message that can be parsed by the SOAP web service. The response is then transformed from SOAP to JSON and routed back to the mobile app.

The Akana API gateway, and comparable products, provide several additional functions for an effective E2M architecture. Chiefly, SOAP web services called by RESTful APIs can be mediated and transformed to other formats, such as MOM and JMS.

In the scenario shown in Figure 3, messaging between the ERP and CRM systems is done using MOM. For those wishing to rely on an API management, Akana’s API gateway can easily provide this mediation.

Security is another factor that must be addressed in the REST-SOAP connection. Why? Because B2B functionality are often subject to more stringent security requirements. REST has not traditionally addressed these needs. For example, if a RESTful API gets a “POST” message, does that mean an order is being placed by the message sender? Who is the message sender anyway?

The API documentation must be clear on what the POST message means. The sender of the POST message needs to be authenticated and authorized if there is a pending transaction. Otherwise, a number of unacceptable security risks arise. Akana’s API gateway is unique in that it can make all of this functionality possible on a single management infrastructure. Akana takes care of RESTful APIs and SOAP services, as well as MOM and JMS transformation requirements.

Benefits of SOAP-to-REST Connection

Once the SOAP-to-REST transformation is possible, businesses can implement more sophisticated corporate mobile programs.

Figure 4 (above) shows a use case for a manufacturer exposing its SOAP web services through a RESTful API. Using this approach, the distributors can develop mobile apps that enable their customers to tap directly into the manufacturer’s back end systems.

Consider a tire manufacturer allowing store customers to use a mobile app to place orders. The app could also be used to change orders, confirm payments, cancel orders, and so forth. The mobile app communicates with the manufacturer’s systems using the RESTful API. But the actual order processing is handled by SOAP web services that communicate with the ERP.

The enterprise-to-mobile/enterprise (E2ME) approach shown in figure 4 is emblematic of how businesses can harness the smartphone revolution. All of the inherent power in the enterprise SOA can now be made available to mobile apps using a protocol that app developers prefer.

Overall, SOAP-to-REST transformation offers a number of advantages including:  

• Speed: SOAP-to-REST is not a push button process. Yet it can be done much more quickly than going back to the IDE and writing new RESTful APIs for enterprise systems.
• Pragmatism: Building RESTful APIs on top of existing SOAP infrastructure allows a business to move into mobile while still using existing SOAP developer tools as well as SOA security and governance platforms.
• Cost: Transforming SOAP into REST is cost effective. The investment has already been made in the SOAP service. There’s no reason to rip it out. Similarly, investments in tooling and management platforms for SOAP can persist as the company implements SOAP-to-REST transformation.

How to Manage the SOAP-to-REST API Lifecycle With Akana

Effective SOAP-to-REST transformation doesn’t happen automatically. APIs that expose enterprise systems need to be managed across the full API lifecycle. If API access is unrestricted, it is nearly impossible to regulate load on the APIs and secure them against threats. In a large and complex corporate API ecosystem, unmanaged APIs are sure to result in service outages, frustration, and inefficient use of IT support resources.

From a business perspective, unmanaged APIs pose a risk of suboptimal execution. When this happens, the app community experiences confusion and loses interest in developing apps that can take advantage of APIs to realize business objectives.

Akana can resolve these issues with our full lifecycle API management solution. The Akana API Management Solution approaches APIs from an end-to-end perspective. We ensure APIs are serving their intended purposes at every stage – from planning and development, to deployment and retirement. Figure 5 (below) shows how this API lifecycle progress is managed by the Akana solution.

When all pieces of the API management process fall into place, your SOAP-to-REST API connection remains secure, streamlined, and efficient. While building a similar approach manually is possible, it is not necessarily scalable. Mobile adoption, digital transformation, and unforeseen emerging trends are challenge the enterprise every year. You can stay ahead by adopting a full lifecycle API management approach.

To learn more about Akana, you can try our 6-month trial free of charge. Or, view our on-demand demo to see how easy it is to get started.

Start Free Trial  ▶️ Watch Demo First 

👉 Become an Expert

• API Basics
• API Lifecycle

This blog was originally published as a white paper in 2015. It has since been updated for accuracy and comprehensiveness.