Cloud Interoperability

MultiCloud: Cloud Interoperability and Communication

After reading the first article about cloud interoperability you might be thinking, “But really, how do separate clouds communicate?” In this article, we are going to look into more of the technical side of how clouds communicate.

Clouds Communicate With APIs

Back in the dark ages for computers, computer programmers and IT were tasked with adapting and customizing various applications, which includes getting them to communicate with one another. To help with the task of getting various applications to communicate with each other they came up with Simple Object Access Protocol or SOAP. SOAP is a protocol specification for exchanging structured information. Today it is used in the implementation of web services in computer networks. More recently, Representational state transfer (REST) emerged as another way cloud systems can communicate with one another on the internet.


SOAP provides the Messaging Protocol layer in the protocol stack for web services. It requires an XML-based message format consisting of:

  • an envelope to define the message’s structure and how it should be processed
  • a set of rules for encoding (expresses occurrences of data types)
  • a set function or data type to be presented when one of the rules are met

The main benefits of SOAP are:

  1. Substantial extensibility of security, WS-routing , etc.
  2. Can operate over any protocol such as HTTP, SMTP, TCP, UDP, or JMS to get passed firewalls
  3. Allows for programming in any language or platform

REST, on the other hand, is newer and easier to use. Unlike SOAP, REST is more of an identification guidelines tool than a protocol for cloud communication. These guidelines are referred to as constraints, REST’s constraints are:

  • Clients-Server: separates the user interface (client) concerns from the data storage (server) concerns. No client context being stored on the server between requests.
  • Stateless: a server can transfer the state of a session to another service, but does not transfer information about the clients or machine.
  • Cacheable: clients and intermediaries can cache responses
  • Uniform Interface: server access data the same way with all clients and servers with no added requirements.
  • Layered System- user can have access to an end server through another intermediate server without knowing the underlined implementations
  • Code on Demand (optional): temporarily extends/customizes the functionality by allowing code from the server to be sent off to the client for execution

Key differences of REST when compared to SOAP are:

  1. Message can be in any language (HTTP, XML, etc.)
  2. No protocol structure (envelope, rules, etc) required
  3. Resistance to system failures within the components, connectors, or data
  4. Mobility of components through moving program code with the data

Using REST APIs is very simple and doesn’t always require knowledge of coding. That is part of the reason why in today’s technology world, REST is more popular with web services than SOAP. Because of this, Acumatica is fully functional on a RESTful API, but we will discuss that in a future article.

Clients First is an expert at implementing  Acumatica, Dynamics AX and Dynamics 365 (which also made it into the leader quadrant). Contact our sales team today by calling 800.331.8382 or emailing Clients First implements and supports clients across the U.S.A. and in 11 countries. Our team of professionals are ready to help implement the best finance and operations solutions for manufacturers, distributors, project-based manufacturers, MRO (maintenance, repair and overhaul), and professional services.

Nucleus Research ERP Technology Value Matrix 2016

Sources: AcumaticaSOAP, REST