Cloud Integration Requirements: Native JSON and REST

One of the primary requirements of an integration platform as a service (iPaaS) and why integration heritage matters in the cloud is that the technology is built on modern web standards – specifically JSON and REST.

JavaScript Object Notation (JSON)

“It’s easy to put rows and columns into a document, but vice-versa doesn’t work.”

– Craig Stewart, Director of SnapLogic Product Management in this recorded demonstration

SnapLogic deals with documents, rather than just the rows and columns of the traditional ETL type tools. In his post, Technical Advantages of JSON-centric iPaaS, SnapLogic’s Chief Scientist Greg Benson reviews 5 data processing and end users benefits of using documents as our native data type:

  1. Documents are a better match to modern web services.
  2. Documents result in more succinct Pipelines.
  3. A document model allows Pipelines to be loosely coupled. (Watch this customer video to hear about the benefits of “schema-less integration”)
  4. A document model allows for greater Pipeline reuse.
  5. Documents are a superset of records.

When it comes to SnapLogic’s foundational support for modern web standards, he writes:

“Our support for documents allows our Snap endpoints to directly consume hierarchical data in native format and send it on to downstream Snaps in a Pipeline. This means that there is no requirement to flatten data into records or to turn a JSON document in a string or BLOB type.”

When it comes to the benefits of a JSON-centric approach supporting structured and unstructured data seamlessly, he concludes, “This native support for documents is one of the many architectural innovations we have developed to help businesses connect both web services and traditional data stores.”

Here is a JSON and Table view of a Twitter Query Snap in the SnapLogic Elastic Integration Platform Designer:

SnapLogic_Native_JSON

SnapLogic_Rows_Columns

Representational State Transfer (REST)

REST_SnapsAs we wrote in the Why Buses Don’t Fly Whitepaper, “Mobile and enterprise APIs are primarily exposed over the REST protocol with the data encoded via JSON. From an integration platform perspective, REST and JSON together are increasingly replacing SOAP and XML, making ESBs less relevant in today?s enterprise SMAC architecture.”

SnapLogic’s architecture is entirely REST-based. We have REST Snaps (as displayed in the screenshot to the right) and REST is how the control plane communicates with the data plane (see the post on Software Defined Integration and the high-level architecture diagram below). As we outlined back in 2011, in the early days of building our new Elastic Integration Platform:

“REST lets you publish your data and have others ? regardless of where they might be ? work with it. Just looking at the URI gives you an indication of how to proceed. Yet despite all of these advantages, basing SnapLogic on REST gave us the same security and massive scalability as the overall Web itself.”

SnapLogic_architecture

In the next modern integration requirements post, we’ll cover connectivity in more detail.

We're hiring!

Discover your next great career opportunity.