Cloud Interoperability and Communication

Our first article about cloud interoperability looked about how clouds work and the fact that they operate separately makes having a way for clouds to communicate a necessity. In this article, we are going to take a more technical look at how look into more of the side of how clouds communicate.

Clouds Communicate With APIs

Back when the internet was still being accessed by dial-up, computer programmers and IT were tasked with adapting and customizing various applications and getting them to communicate with one another. To help with this task, 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 that includes:

  • 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 any of the rules are met

The main benefits of SOAP are:

  1. Security and WS-routing is significantly extendable
  2. Can operate over any protocol (such as HTTP, SMTP, TCP, UDP, or JMS) to get passed firewalls
  3. Any programming language or platform can be used

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 can be 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 the machine.
  • Cacheable: clients and intermediaries can cache responses.
  • Uniform Interface: server accesses 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 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. The entire message can be in any language (HTTP, XML, etc.)
  2. No protocol structure (envelope, rules, etc.) required
  3. Has natural resistance to system failures within the components, connectors, or data
  4. Mobility of components, simply move 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 Original article:

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.