EDI vs API
Have you ever wondered if those "EDI vs. API" articles are legit and why they got it all wrong?!? EDI and API are different references to the same concept, e.g., they are essentially the same thing.
From Wikipedia:
- Electronic data interchange (EDI) is the concept of businesses electronically communicating information. Wikipedia - Electronic data interchange
- An application programming interface (API) is a way for two or more computer programs to communicate with each other. Wikipedia - API
Our "Why we created our EDI API?" article offers a different perspective on the "EDI vs.API" narrative. Let's dive into the essence of EDI and API.
EDI = API
No, that's not misspelled, EDI is equivalent to API. Not convinced? Read on.
We are well aware that every object is defined by the collection of its properties. In order to establish how EDI and API relate to each other we need first to understand what they are.
| Premise | EDI | API | Conslusion |
|---|---|---|---|
| Purpose or why does it exist | To provide a standard electronic format that replaces paper-based documents, and automates the movement of information between organizations. | To simplify software programming by abstracting the underlying implementation and only exposing objects or actions the consumer needs. |
EDI = API Both provide reliable electronic communication between software applications and businesses (B2B) that can be automated. |
| Physical medium or what is it made of | EDI files and EDI translation software. |
API requests/responses, which can contain files or file contents. Software programs that implement the API functionality. |
EDI = API Both dictate data to be exchanged in electronic form, usually files or payloads. Both require software that interchanges and parses/generates the data. |
| Design or what does it look like |
Any software application that ensures: - the data adheres to the EDI standards - the communication must is safe and reliable
|
Any software application that ensures: - the data adheres to the API docs - the communication must is safe and reliable
|
EDI = API Both require the data that is exchanged must be formatted according to agreed rules/specifications. The rules are not physically enforceable and it is up to every actor to ensure compliance. Both emphasise that the communication must be secure, and reliable and allow for synchronous/asynchronous patterns. |
| Implementation or how does it work |
The common example is interchanging EDI (X12, EDIFACT, HL7) files via AS2/SFTP. Another example is interchanging EDI (X12, EDIFACT, HL7) files via a REST API. See EdiNation
|
The common example is sending/receiving JSON payloads via HTTP. Another example is sending EDI files as binary payloads and returning their corresponding JSON, or vice versa. See EdiNation |
EDI = API Files or payloads are transported via secure channels. Senders and receivers use special software that can translate the data between external and internal formats. High-level flows define multiple exchanges (conversations) and acknowledgments to complete a specific business function. These flows usually extend into integration with other software systems such as ERPs and databases. |
EDI or API
Many of the EDI vs API articles suggest that the two are mutually exclusive, and purport you must choose either one or the other, but not both. The backing for this is as incompetent as it is obscure. A popular misconception can be found on the EdiBasics site:
| Property | EDI | API | Our verdict |
|---|---|---|---|
| Call pattern | Asynchronous call for batch exchange | Synchronous call for real-time exchange | Misleading. Both EDI and API allow for batch exchanges, and APIs can implement both synchronous and asynchronous patterns. |
| Data size | Capable of handling mass data | Not intended for mass data | Incorrect. Both can handle and are intended for mass data, just think of video streaming and file uploading APIs. |
| Standards | Standards are set with industry and region-specific options | No widespread and established standards | Incorrect. Both must adhere to standards. EDI is supposed to be centralized, but in reality, it's an agreement between the partners. Exactly as it is in APIs. |
| Security | Trusted solution to fulfill compliance regulations | May not be suitable to adhere to compliance regulations | Incorrect. APIs can adhere to any regulation. Example - online banking and healthcare applications. |
| Ease of on-boarding | New partners, especially those who are pre-connected to provider’s network, can be on-boarded easily and quickly | The data layer for API implementation needs to be built | Misleading. Both could share the same software that onboard new partners regardless of whether it is installed in an EDI system or in an API. |
| Cost | Usually charged by kilo-character (KC) | Usually charged by document | Irrelevant. The price depends on the provider, so it is irrelevant to EDI or API. EDI software is very expensive. API software is less expensive. |
| Common use cases | Batch data conversion of bundled information via system-to-system Connect to external trading partners via VAN |
Real-time single request for information Connect to API-enabled cloud applications |
Misleading. B2B communication for both single and batch payloads is a common scenario for APIs. Public-facing APIs are de facto a standard these days. |
The general premise of the "EDI vs API" stereotype is one-sided and usually presented from an EDI-defending perspective as a warning for anyone who might consider a different solution to their business problems.
The goal of this article is not to favor API or EDI but instead to show that there are no technical or other impediments for EDI and API to co-exist and complement each other.
It is obvious that a lot of the confusion in the definition of EDI and API is caused by the assumption that the common implementations of EDI and API are radically different, e.g.,
- API is the synchronous exchange of small payloads in JSON format via HTTP
- EDI is the asynchronous exchange of batches of X12 or EDIFACT transactions as text files over AS2
The "EDI vs API" articles main point is that the two mainstream implementations are so widespread that replacing one with the other would be a very complex and costly task. But they fail to develop this point further and provide an assessment on the option of utilizing a hybrid EDI and API solution or complementing EDI with API.
EDI and API
Let's be honest. EDI and API, as definitions, start from two different perspectives - EDI from the business side and API from the developers' side. However, at the end of the day, they both converge to the same junction and can be explained as a secure exchange of formatted data. It doesn't matter how the data is formatted, whether it's business or application data, and how it is transported. All these secondary factors are due to the particular software, brand, and implementation.
The general conclusion about EDI and API can be summarized as follows:
- EDI and API exchange formatted data. The data adheres to standards (X12, EDIFACT, API docs). These standards must be agreed by the partners involved, although EDI provides centralized governance for standards.
- EDI and API must securely and reliably transport data from one point to another. This process is independent of the contents and format of the data.
- EDI and API require specialized software to be installed and configured at both the sender and the receiver, in such a way that they can transport formatted data and be able to read/make sense of that data by being compliant with the standards (X12, EDIFACT, API docs).
We already showed that both EDI and API could exchange formatted data (X12, EDIFACT, API docs) over various communication protocols (HTTP, AS2, SFT). So in order to finalize this discussion, we need to show that specialized software able to read/create the various EDI-specific formats (X12, EDIFACT, HL7, etc.) can both run in APIs or be used as an adapter between EDI and API.
Let's discuss the following use cases:
- From API to EDI - an organization that is familiar with API wants to connect to another organization via EDI. This is a very common scenario, and the obvious solution would be to sign up for a managed provider or VAN. But what about implementing this in-house? All that is required is a software toolkit that translates between the API docs that the organization uses internally and the EDI formats. I'll leave the transport out because the options for transferring files over the Internet nowadays are ubiquitous.
- From EDI to API - an organization that is familiar with EDI wants to connect to another organization via API. This is a less common scenario, and a solution would be to create a custom integration. All that is required is a software toolkit that translates between the EDI formats to the API docs of the destination organization.
The solution to utilizing EDI as an API is a software toolkit to translate between the two. This is the only missing link from bridging EDI and API, using them as complementary patterns instead of competing options.
The good news is that we already offer such a software toolkit, EDI API, which helps developers to add EDI capabilities to their software, regardless of the programming language they use. Our EDI API provides a technical solution to convert between the various EDI formats (X12, EDIFACT, HL7, etc.) and their corresponding JSON representation, and specifies an open-source meta-format, OpenEDI, that standardizes the JSON representation of each EDI message type.
Comments
0 comments
Please sign in to leave a comment.