Integration

What's the difference between SOAP and REST?

SOAP and REST two different approaches to online data transmission. Specifically, both define how to build application programming interfaces (APIs), which allow data to be communicated between web applications. SOAP, short for Simple Object Access Protocol, is an official protocol maintained by the World Wide Web Consortium (W3C). REST, or Representational State Transfer, is not a protocol, but a set of architectural principles that offers an alternative to SOAP. Typically, an API will adhere to either SOAP or REST, depending on the scenario and the preferences of individual developers.

SOAP: Simple Object Access Protocol

Simple Object Access Protocol (SOAP) is a standard protocol that was first designed so that applications built with different languages and on different platforms could communicate. Because it is a protocol, it imposes built-in rules that increase its complexity and overhead, which can lead to longer page load times. However, these standards also offer built-in compliances that can make it preferable for enterprise scenarios. The built-in compliance standards include security and ACID (Atomicity, Consistency, Isolation, Durability), which is a set of properties for ensuring reliable database transactions.

When a request for data is sent to a SOAP API, it can be handled through any of the application layer protocols like HTTP (for web browsers), SMTP (for email), and others. However, once a request is received, APIs designed for SOAP must encode their return messages only as XML documents, which is a markup language that is both human and machine-readable. A completed request to a SOAP API is not cacheable by a browser, so it cannot be accessed later without resending to the API.

REST: Representational State Transfer

Representational State Transfer (REST) is not a protocol like SOAP, but is instead a set of architectural principles that is more attuned to the needs of lightweight web and mobile applications. Because it is a set of guidelines, it leaves the implementation of these recommendations to developers.

When a request for data is sent to a REST API, it is usually handled through HTTP. Once a request is received, APIs designed for REST (called RESTful) can return messages in a variety of formats, namely HTML, XML, plain text, and JSON—in particular, JSON (JavaScript Object Notation) is favored because it is a language-agnostic (despite the name), human and machine-readable, and lightweight data-interchange format. In this way, RESTful APIs allow greater flexibility and can be simpler to set up.

An application is said to be RESTful if it follows six architectural guidelines. A RESTful application must have:

  1. A client-server architecture composed of clients, servers, and resources.
  2. Stateless client-server communication, meaning no client content is stored on the server between requests. Information about the session’s state is instead held with the client.
  3. Cacheable data to eliminate the need for some client-server interactions.
  4. A uniform interface between components so that information is transferred in a standardized form instead of specific to an application’s needs. This is described by Roy Fielding, the originator of REST, as “the central feature that distinguishes the REST architectural style from other network-based styles.”
  5. A layered system constraint, where client-server interactions can be mediated by hierarchical layers.
  6. Code on demand, allowing servers to extend the functionality of a client by transferring executable code (though also reducing visibility, making this an optional guideline).

SOAP vs REST

In short, SOAP is a protocol with specific requirements like XML messaging, whereas REST is a set of guidelines that offers flexible implementation. SOAP was developed first, and so many legacy systems may still adhere to it, while REST came later and is often viewed as a faster alternative in web-based scenarios.

SOAP APIs have built-in security and transaction compliance that align with many enterprise needs, but that also makes them heavier-weight. REST APIs are more lightweight, making them ideal for newer contexts like the Internet of Things (IoT) or mobile application development. Additionally, many public APIs, like the Google Maps API, follow the REST guidelines.

APIs and Red Hat

Red Hat gives you modular, lightweight, and comprehensive API solutions that are open source, open standards, and available on-premise or in the cloud. They're a big part of how you can change your existing integration infrastructure to be more flexible and deliver value more rapidly.

Platform

Integrate your diverse IT assets with a distributed, flexible integration platform. Red Hat Fuse provides the infrastructure and tooling you need to integrate everything.

Platform

Manage your APIs for internal and external users with a platform that makes APIs easy to share, secure, distribute, control, and monetize.