LS Retail
Microsoft Dynamics NAV
AS 400
Shopify Plus
D365 Business Central
Netsuite
D365 Finance and Operations
Blue Link ERP
Shopify EDI
Think of the last time you ordered something online. What was your experience?
Did you feel confident that your payment had been accepted? Was there a delay in your email confirmation of your order that made you second-guess your decisions? Were you issued a tracking number once your package shipped?
…Did you feel confident about the experience?
The top-tier ecommerce stores and marketplaces have been subconsciously training our consumer expectations so that when our expectations aren’t validated by automated emails, notifications, and receipts, we begin to have doubts (and even mild consumer anxiety). The Amazon customer experience, as one example, is so slick that you’re likely to not have thought twice while adding an item to your cart and clicking ‘1-Click to Checkout’ — you don’t even need to actively authorize PayPal to debit your accounts if you’re a Prime member. And you never have any doubts on whether or not your item(s) will arrive when ordering Prime, either; those cheerily-wrapped packages with the branded ‘Amazon Prime’ tape almost never fail to show up on your doorstep in the coming days.
Integrating your Amazon Marketplace Data – Download the Ebook
But what does this mean to your business, your customers, and your customers’ experiences? What does customer experience have to do with data integration?
Surprising to many, APIs, EDI, and data automation via integration play a huge role in forming customer experience, good or bad. From the first click, down to the last mile, APIs are the messengers between otherwise disparate applications and islands of technology; they keep everything tied together and working (provided the quality of your integrations match your business’s strategy, volume, and more).
But what are APIs anyway, and why are they the EDI of the 21st century? Keep reading to find out.
APIs are the new EDI
In the 1990’s and 2000’s, complex retail supply chains depended on EDI to transact electronic data between themselves and their supply chain partners. Typically partners transacted orders, invoices and shipment notices in non-real time; EDI was store and forward technology.
While EDI isn’t going anywhere, along came the internet. And with the internet came APIs, turning the world of data communication on its heads in terms of possibilities and flexibility. As web applications proliferated, the standard of communication between applications became the API.
So what is an API?
The technical definition of an API is ‘Application Programming Interface’. It’s easy to slip into hyper-technical terminology when talking APIs and data integration — something we’ll leave to the experts for the purposes of this article — but envisage them as interfaces that allow you to access data from various systems in real-time. The applications can be on-premise or in the cloud, or both. APIs are the ‘socket’ to the ‘extension chord’ of data integration services and platforms like VL OMNI, allowing us to take data from one source and automatically transform and transport said data to one target application, or many target applications (and back, too).
APIs and the connections between them are the plumbing of the internet of things. To help set context, let’s review definitions first.
APIs can typically be divided into two categories – public and private.
Public facing APIs expose data to the outside world. Private APIs expose data to a protected inside world. As of this writing Programmableweb has cataloged over 18000 public APIs (up from 14000 this time last year), and over 7900 (up from 7300) API mashups. It’s huge.
Integrate and automate application data strategically with VL OMNI: Learn more
How do APIs work?
APIs typically have a number of sub-components which, together, make up the actual API itself. The first is communications; the second is security; and last is the payload — AKA, the actual data being made available for export from the application via the API. If the data you’re looking to automate in and out of an application isn’t part of the API, you’re unfortunately out of luck, but if it is, you’re open to a world of possibilities in data movement.
There are two API communications approaches that are widely used today: SOAP and REST.
SOAP is the granddaddy of API communication protocols, and is defined as Simple Object Access Protocol. It is one piece in the web services stack and is usually paired with application layer protocols like HTTP and SMTP. The other application layers provide security, and the payload is XML. The current SOAP definitions by W3C were last updated in 2007, so some would say SOAP is getting a little long in the tooth… bringing us to REST APIs.
REST stands for Representational State Transfer.
…What?
You can relax, REST APIs are really not that complicated. The concept behind REST is that it uses simpler mechanisms to communicate, rather than using more complex mechanisms like SOAP and RPC (Remote Procedure Calls). RESTful applications use HTTP to post, delete and read data. There are four HTTP methods used in REST; GET, POST, PUT and DELETE. Due to its flexibility, there is pretty much anything that can be done with REST. Some have even postulated that the Internet is the largest REST application in the world.
So what is the difference between SOAP and REST APIs? First is the payload. The SOAP payload is XML, where as the REST payload is XML, or JSON, or both. JSON is a lighter-weight and more compact message protocol.
Understanding the nature of the API gives you a clear indication as to the complexity of the integration. Today, the API world is moving more and more to REST based approaches with the flexibility of an XML or JSON payload.
APIs: Business models solution providers have put in place
Looking at the business model will help explain the type of integration approach and the role the application provider will play. It’s also the interesting part for non-techies: the business models are surprisingly complex.
There is a belief in the internet world that APIs and access to them are free, but in most cases that is not reality. In fact, in a blog article in early 2013 elastic web identified 18 business models that existed in the world of APIs. By late 2013, Programmable web had identified 20 API business models. The presentation below walks through the 20 models that had been identified at that time.
What’s interesting in the deconstruction done by elasticweb and Programmableweb is that the top tier, in reality, represents only four models: Free, developer pays, developer gets paid, and indirect.
Each of the last three then have multiple apporaches that reflect the application and their monetization strategy.
What these models tell us is that there are multiple integration strategies required, depending on the type of solution you’re looking to build and/or implement.
So aside from the monetization strategy, APIs are important to a business for the following reasons, and should form part of a proper data usage and integration strategy.
APIs create stickiness; its no secret integration is time consuming and expensive. So, do it properly from the beginning. APIs are useful in extending the usability of a platform. The more third-party applications that connect to an API, the more extensive the use case for that solution is.
APIs also allow for more complex interactions; that’s why they are the EDI of the 21st century.
