EDI and OpenAPI

EDI vs. API

Perhaps you have seen some of those articles on the Internet comparing EDI to API, obviously suggesting that the two are mutually exclusive and can't be perceived in accord with each other, thus prompting for a decision to choose either one but not both. This is usually a sign of misconception and is used to favor one approach over the other, depending on the author's preference rather than any technological evidence.

EDI and API

As far as the translation and validation of EDI documents are concerned, EDI and API can live happily together, and anyone exploring their options in this day and age has the unique opportunity to get the best of both worlds. No more EDI vs. API type of ill-conceived and misleading articles, because EDI, which is also an API, already exists, is already used by businesses and is undoubtedly part of the future of EDI.

EDI meta-formats

EDI transactions are described by a set of format documents, or implementation guidelines, mappings, or specs; you name it. This meta-format, describing the format of every EDI document in the way the creator of the document intends it to look like, is at the core of all underlying applications or software systems that will be processing those EDI documents. There are a few main meta-formats in use today, IBM uses SEF,  Microsoft uses XSD, EdiFabric uses .NET attributes and C# classes, etc. and a multitude of incompatible vendor-specific and proprietary scripts and languages.

The obvious problems here are 1) that the meta-formats that exist today are incompatible with each other, hence an investment in one of them results in a limited choice of EDI software, resources, and vendors to only those that are consistent with the chosen meta-format; and 2) that none of the existing meta-formats is easily applicable to the Web or APIs, hence supporting the presumption that EDI is a legacy technology that is ill-suited for the Internet.

EDI and OpenAPI

OpenAPI, or The OpenAPI Specification is a broadly adopted industry standard for describing modern APIs. It is language-agnostic, open-source and is maintained/supported by the likes of 3Scale,  Apigee, Capital One, Google, IBM, Intuit, Microsoft, PayPal.

As of now, OpenAPI can also be used as a meta-format to describe EDI documents. This allows software developers and software systems, regardless of the programming language or technology they rely on, to quickly adopt EDI in a standard, open and modern way. EDI documents can finally:

  1. Be represented as Open API schemas in YAML, JSON or XML format, just like any other API model
  2. Translated and validated via REST APIs
  3. Have their specification shared between all Web applications without the need for conversion

 

 

Was this article helpful?
0 out of 0 found this helpful