EDI is a standardized data format with some blessed transport protocols that ensure disparate systems can communicate without needing custom integrations.
I've never heard someone try to make the case that it's an API per-say. More like a data format, such as JSON, with prescribed elements, etc. What the other end-system does with that data is up to them... and not all data is intended for pure automated programatic consumption (ie. invoices, etc).
The main issue with EDI is your industry either has embraced EDI or it hasn't... making it really difficult to use EDI if only a small subset of your manufacturers/vendors also support EDI. Typically organizations these days will support a REST API instead of EDI, which obviously requires quite a lot of custom integration work (even if using generation tools like swagger/openapi).
Our EDI code probably has multiple if blocks for every customer we communicate with.
Implementing EDI is not for the faint of heart. For the variations I worked with, there was little useful documentation, I learned mostly be reading existing code. I would hate to have to start from scratch.
I wrote an EDI parser from scratch some years ago (2 to 5, really don't remember). Almost until the end I kept second-guessing myself. It all looked so flimsy.
Eventually I made a second parser that utilized a parser-combinator library (the first one was hand-rolled) and devised extremely detailed property tests that I ran against both parsers. Only then did I feel confident.
Naturally, in production the code crashed on the second day because OF COURSE the senders didn't obey the EDI[FACT] spec and had quirky deviations from it.
Shit like that makes people retire to the mountains and never touch a computer again, man.
This is so true. Am in logistics so can't speak to other verticals but every-single-implementation has something unique to it. Either they're on a version we haven't tested on, or they only support some date/time formats, or they have custom codes, whatever.
Also in logistics, and agree. There is danger in over-promising with customizations. If you're not careful to you can spend more time and money meeting what the customer wants than the actual business the customer brings in.
Agreed, everyone needs something just a little different. And at least from my experience, the platforms and systems that build the integration are essentially disparate and held together with I.T. brand duct tape.
I worked at a healthcare company at my last job and dealt with the X12 EDI. We had several ETL processes just to convert X12 834s (benefits/membership enrollment) into a common file format because every client seemed to do something different that was not part of the spec. It was hard because we would get the data from clients and since we were taking their money we had to accommodate their butchering of the specs. The thing is, though, that many of the files we received were generated from a COBOL program and then moved to our SFTP server. It isn't like there are many (if any) COBOL libraries that validate or enforce the standards and it isn't like they would be able to just update their COBOL programs to make API calls either.
I second that; it is the core of all EDI issues. Outdated software and ancient complex maps that no one dares touch. That's why so many adapter/data cleansing projects spring up to isolate the COBOL-style software from the rest.
I used to do implementations for an EDI provider. They were almost always custom. I am shocked there’s a belief that it isn’t custom. Most projects took weeks to just setup a single partner relationship.
There are companies that can help with EDI integrations so that both ends can use their "flavor" of EDI and they do the translation. SPS Commerce is one such company I know of. Not affiliated, but we do use them at my employer. I don't work on that team, though, can't offer any thing in terms of ease of use, pricing, etc.
Vans sound convenient but are really just another potential problem in the chain. I only use them when the other side insists on some truely inconvenient protocol I don't want to have to set up and maintain a special windows vm just to run a special client for one customer-of-a-customer.
Except that from my own experience connecting to EDI needs more custom programming than connecting to RESt APIs. The format is horrible and also the whole workflow based around sending and receiving messages
A standardized data format with some standardized transport protocols... how is that _not_ an API?
I don't think whether the integrations need customization or not is relevant. Certainly many API's are "bespoke" and need custom integrations. But if it's designed to be standardized (whether it succeeds or fails, and many standards end up not being so standard), that certainly doesn't somehow disqualify it from being an API either.
It might be a difficult or easy API to work with; or how difficult or easy it is may depend on your context and platform.
It's just the data format. There is no EDI transport protocol. JSON, XML, PDF etc, they aren't APIs. Neither is EDI. You can email a JSON file, you can sent it over http, you can FTP it, you can transport it a lot of ways. JSON isn't an API. EDI is the same(but way more detailed...).
There isn't a JSON transport protocol either. And EDI is not a format; it's a general reference for multiple data standards and the rules for exchanging data instances of them.
One of the issues is that people have different opinions of what EDI is, which is confusing, pretty much as what their views about API are. Although the definition of EDI and API is expected to be "standardized", everyone seems to have their own flavor of it :) Pun intended.
Which is why people use email, ftp, http and more to send JSON.
EDI is much more concrete than API. EDI has version/standards issues, but it's a pretty concrete thing and the different versions/standards are highly specified. API is vague, but generally there is a requirement that the API does something or represents something that does something.
EDI doesn't really meet any definition of API...it doesn't do anything.
The different EDI standards are pretty explicit about the sequence of messages (276/277, etc.), acknowledgments (technical, functional, etc.), and conversation items (interchange IDs, duplicates, sender/receiver IDs, etc.). And yes, there is a requirement that EDI transactions do something or represent something that does something, in a specific way.
EDI does a lot of things, but its transport and semantics are visibly decoupled, whereas in web APIs, they appear to be somewhat uniform.
Web API is far from vague; on the contrary, it might even be more stringent (and selective) as the inbound data goes via multiple stages of validation as opposed to EDI, which does "take-all" data, then either "parse all" or "reject-all".
Work in transportation. We refer to them as EDI and API and often phrase it "We can do EDI or API.". So we don't think of them as the same thing. Goals are the same most of the time, but I never really think of EDI as AN API.
But the whole debate is a little pedantic for me. Just need to get it working ...
This whole thing is like if Google insisted gRPC wasn't an API framework, it was just gRPC and indoctrinated every engineer that went through its ranks over the decades to perpetuate the same in other companies they join.
A calling convention is an API, an ABI is an API, and I am even okay with going as far as saying "walking into a convenience store, talking to a clerk in a human language to retrieve items in exchange of paper currency" is an API.
> and I am even okay with going as far as saying "walking into a convenience store, talking to a clerk in a human language to retrieve items in exchange of paper currency" is an API.
I think that is a bit far. Social customs define some sort of interface we use to complete transactions, but it is not programmable nor dealing with applications.
Yeah that bit is definitely a stretch. I was debating whether I should go as far as making that statement as well.
Its gets the point across but certainly a stretch. We are neither applications nor is the convention well-defined in that example, but the point stands.
> and I am even okay with going as far as saying "walking into a convenience store, talking to a clerk in a human language to retrieve items in exchange of paper currency" is an API.
This is more apt to call a protocol than an API. An API could conform to this protocol though, in a manner of speaking.
This is weird because in my whole experience with EDI... I'd almost rather grab the SOAP.
- In one case, a Bank's EDI Check format did not follow the spec. Long story short they decided to (either leave out or repurpose) the leftmost digit of the check field block for their own purposes. This made it -extremely- difficult and convoluted to properly parse their response files and match them up to our internal files in edge cases where the client had fairly high check numbers. The response from the bank was something along the lines of "It's just a specification we can do what we want with it." facepalm
- In another case, a Client had a proper EDI spec and followed it, but to both upload and download files, you had to use a special custom (non-standard) FTP commands to deal with a 'mailbox'. It was a 'fun' challenge to write a parser to automate the upload/download process, but it was definitely a challenge to do in a way that fit in well with our other processes.
Mind you, that's not to say that XML is necessarily better. EDI (if the data fits well to the size constraints) is FAR more compact, (if the specification is well written and sane) can be pretty dang simple to write a reliable AND fast parser for, and in some ways the constraints themselves are useful in helping to make sure that use cases are fairly well targeted (vs some XML/JSON dumps where you care about 5 fields out of 35).
I forgot what it was called but I know that mailbox ftp thing. Pain in my --- writing custom parsers and scripts and wrappers just for that one vendor of just one of our clients.
I'd still take that over the really proprietary stuff some were using where there was no unix or linux way to do it and there just had to be a windows box somewhere just to run the special client.
And then there was the weird windows ftp server with the 3rd party ssl add-on, Glub-tech? That didn't even conform to the ftp specs at the lower packet/protocol level such that it wasn't just a matter of parsing unusual text output or taking unusual commands, normal ftp clients would fail to negotiate the basics and definitely failed to negotiate ssl because it was doing part of the handshake out of order. The only way to work was to use their own java client. That one thing was the only reason I even had to have a jre existing on the system at all. Eventually that aged out when that vendor-of-a-customer finally upgraded their windows server and the new one had native ftps which was conformant enough to work.
And all these things are stuff used not even by own own customers but by vendors and customers of our customers. I had approximately zero influence to get the remote party to fix their broken shit, Yet, for our customers, still had to make things work.
At least that mailbox thing with it's weird thing where deleted or processed files were still listed and you had to look at some flag/status characters to tell if a file was really new or should be ignored, not the filename, because that could be the same, at least any normal ftp client worked with it and the problem was merely parsing the text sent back from the server, and I think also issuing comments that were a bit custom and needed to use the QUOT command instead of the standard convenience commands in the client.
Whatever that's what I got paid for was being good at finding ways around stuff like that. I didn't actually mind solving those problems even though at the same time I can observe that "x is shit" and they shouldn't be using it and they wouldn't have to pay so much for difficult problem solving if they weren't using x weird shit product or service.
Isn't it crazy that X12 standards come out and are constantly updated to provide a way to send all the data you need in a standardized format however ALMOST EVERY receiver or sender likes to have their own flavor of it, making it near useless. I would rather just call it what it is and just make seperate systems to intake every new customers format instead of rewrite the existing one to work with the currently implemented flavor
So true. The purpose of EDI/X12 was to be the single source of truth. It was okay while the military used it, as they would have stricter control over the standard, but once it was unleashed into the world of business...
There is not much point in it other than every customer is not starting from a plain slate but modifies the existing format to their needs and reuses the COBOL-style software to parse/generate the files. It's the path of least resistance.
When I worked at Electronic Data Systems (EDS) in the 90s, I was doing development on applications that both produced and ingested EDI documents based on a custom EDI standard General Motors imposed on both internal and external suppliers for Shipping Schedule (862) and Planning Schedule with Release Capability (830) documents. GM was able to persuade many EDI software companies to include the GM specs in EDI software releases.
I've heard EDI used both ways: referring to the very general concept of two systems exchanging data in which case an API is a way to implement EDI, and as a file format analogous to json often using ascii control characters (file separator, group separator, record separator, etc)
(tangent)
Also, in the spirit of aiding understanding (and maybe helping non-native English speakers / writers), it's
per se ("in itself", from Latin)
not
per-say (which is not a word -- though it'd be pronounced the same).
EDI is standardized; however, the standard is not enforceable. So it's not like you can't send crappy data or some custom flavor of the format.
The problem is that the receiver of this "standardized" data has to work with it, although it often doesn't comply with the standard.
It's pretty much offloading all pain/responsibility to the other side. But you can do that with a web API, too - send a bad JSON over.
The only difference between working around the formatting issues, EDI or JSON, is the tooling. Developer toolkits for API are far more modern and advanced and have a higher pool of developers to choose from.
Since this is an article about pedantry, I am sick of people conflating "API" with REST or HTTP. Applications had Programmable Interfaces before HTTP even existed.
Services hosted over the internet that let you make requests are a special case of "API" as far as I am concerned. System libraries and third party libraries are the most widely used kind of API, and it's not even close.
Agreed always bugged me too. We have both a .NET library and a web API product, and I still can't tell when customers refer to our API, whether they mean the library or the web API.
It's another case where everybody has their own opinion/meaning for the same words/abbreviations.
But originally, API started off as the "Application Programming Interface" and then was hijacked by the web hype.
"What is an API?" is one of my favorite interview questions.
Your answer gets full points. Partial credit for knowing what the initialism stands for, and having some valid explanation in the context of HTTP.
As another example, one of my internships involved development of software patches so that the company's software could interact with various electron microscopes via their proprietary APIs.
Can you steelman allowing terminology to evolve and allowing new forms to be the assumed/default meaning? Also, context matters a lot. It's rarely ambiguous if we're talking about networking or libraries. When they overlap in conversation you'd need to clarify anyway.
> Can you steelman allowing terminology to evolve and allowing new forms to be the assumed/default meaning?
Obviously, terminology does evolve over time. The word "hat", for example, has a default meaning of "baseball hat", even though the default meaning was something else decades / centuries ago. Baseball hats are by far the most common kind of hat, so it makes sense for the to be the default.
This is not at all what is happening in the case of "API", which is why it annoys me. Hardware APIs and library APIs dwarf the use of REST APIs. But web developers have this tendency to think that what they do is the only thing that is relevant. Therefore, they think API == REST.
It is like if a bitcoin advocate used the term "coin" to refer only to bitcoin, and "metal coin" to refer to regular coins. They want bitcoin to be the default meaning of "coin", but it isn't and it causes confusion in regular conversation.
EDI is not API. Likewise, compression is not encryption, even though the output of a compression routine sometimes appears encrypted. A noun is not a verb, despite them both being parts of speech.
EDI is an acronym for Electronic Data Interchange that uses a standardized format. In that way businesses don't need to send paper around. An EDIs standardized format is implementated with methods that are accessed through an API.
"An EDIs standardized format is implementated with methods that are accessed through an API." - so true. Then everyone starts calling this either EDI or API for short :)
+1 I like your syllogism. API isn't EDI if you apply any logic to determine this.
The article's goal was to dispel the typical pitting of EDI vs. API by showing that EDI can be API.
Correct. And Alma Cogan is dead, but being Alma Cogan is not equivalent to being dead. They have other properties that differ. This article claims the two are equivalent.
Dang, I missed the reference. Thanks for the link.
And while obviously my argument is overly simplified to make a short comment, I find the article's arguments ridiculously absurd. I suppose I shouldn't expect more from a page that's just marketing material for their company.
I'm unsure why the distinction matters that was brought up in the post. It really comes down to what do you need to support, and how much weight you can swing.
Are you a small time supplier, and want a major retailer to integrate with you over API? good luck. The decision really isn't yours, if you want to get paid, you integrate.
I think the reality is that most developers would rather use an JSON API instead of EDI. EDI is sometimes talked about as just X12 / EDIFACT, but the protocol is baked in as well, which causes more headache (who wants to build an EDI stack?). X12 was built during a time where VANs probably connectivity, and caused per character, so everything was positional based and inferred. Modern APIs are descriptive, and easier to use.
(fd: I work for Orderful, a company that provides an API and then translates it to EDI so you can easily work with any trading partner)
I work at a supply chain company that deals with both APIs and EDI and the product people view EDI as a crappier version of an API, which is one of those statements that is so meaningless that it's not even wrong.
Stedi is so good and their new features with guides, mappings and so on, are incredible. Their on-boarding is also second to none, hands down the best experience I’ve had with a vendor in twenty years of professional development. Highly recommended.
Oh. I didn’t realize EdiFabric was your baby. Sorry, man. If it’s any consolation now I feel bad. I previously had a bad experience trying to map from a company’s bespoke data model to EDI in C# using EdiFabric. It’s honestly more of a judgment of C# reflection than anything. We started to roll our own solution because of it, and then discovered Stedi.
Ah, no worries mate, it's a software toolkit and not a pizza - can't make everyone happy. We are in the business of simplifying things for devs, and I'm sorry that you had a bad experience with our product, but if you found a better option that works for you, then I'm pleased.
Generally, EDI doesn't really contain the bits about telling another system what to do. You could build an API on a base of EDI data/document types but there will still be missing bits about semantics and protocol that will have to be filled in by your API description.
If the API is "put EDI files into this directory on the FTP server" then, yeah, it is an API of sorts. Presumably there is an automated batch process that reads the files and perhaps generates responses.
I think what people are asking for when they want API rather than "just EDI" is that they want something their software can use, that gives results and error codes they can understand, so that they can orchestrate and debug the process. Also, they probably want something they can implement without paying thousands of dollars to an intellectual property holder just so they can read and write the messages.
EDI is an awesome spec, and I mean that in the “Mt. Everest is awesome” sense: it is an incredibly detailed tome covering every conceivable business data exchange; with an encoding protocol that is very efficient/succinct.
If you have access to the spec, EDI is easy and kind of fun, if you’re into parsing and manipulating data.
It is in no way an API. It’s a spec that tells you in painful detail how to write out your B2B quotes/orders/corrections/receipts/etc.
Ironically, despite the elaborate spec most participants will wind up just using an ad hoc convention of embedding critical information in non-semantic text fields (or "note segments") with bespoke codes & delimiters.
> If you have access to the spec, EDI is easy and kind of fun, if you’re into parsing and manipulating data.
Yeah. And for the next business partner, you will have the same kind of "fun". And for the one after that, again. Ad infinitum.
In the real world, you will not even handle simple stuff like purchase orders without some kind of special case for every customer. Not in the parsing part, that's the one thing that works pretty well, but in how to interpret the data afterwards.
If you export your contacts in one e-mail program and import it into another, the import and export functions are kinds of APIs, but the exported format isn't.
The interchange format becomes an API if you encode requests in it. Along that axis, it can become a programming language that defines a new API.
If the interchange data does nothing beyond storing a representation of itself, which is then operated upon by some procedures not specified in that data itself, then it's not an API.
I'd say the fact that an API is JSON is a huge technical impediment to EDI. While JSON is great, it's incredibly verbose and not a great format for large amounts of data. Also let's face it, while one can design with effort an API that is capable of all the requirements of EDI, the vast majority of APIs out there are not implemented in this fashion. I just am having a hard time agreeing with this article at all.
The article outlines that API IS NOT JSON over HTTP, albeit it's the most popular case.
You can send a text file/binary (that contains X12, EDIFACT) to an API as easily as JSON.
In fact, that's what EdiNation does; it allows you to send EDI files to a web API. So it shouldn't matter if you deal with EDI or JSON, just convert one to the other, and off you go. Another way to do what everybody else is doing anyway.
In healthcare I think the EDI would be considered HL7 if I am reading this correctly. I worked with HL7 for a number of years and it is absolutely horrendous. It does work just well enough and is just fast enough though. So much of the issues of creating larger scale health exchanges in the USA I attribute to monopolies in the industry (Cerner/Epic) and things like HL7.
I work with EDI (German energy industry) in a well regulated and accepted manner, no exceptions - and still our companies USP is that we provide a sane restful JSON API over EDI. It often feels like many developers simply don't feel the effort to learn the ins and outs is worth the effort.
Yep, that's becoming mainstream. UNECE is currently working on a JSON schema for EDIFACT, due next year, as far as I'm aware.
The EDI standard was made independent from the transport (AS2, SFTP, etc.), so files can be transferred in any reliable/secure way, even web API/HTTP.
With this UNECE initiative, it begins to separate the syntax from the specification, e.g., to be able to transport an invoice as both a text file in EDIFACT syntax, and a JSON file in a matching hierarchy/structure.
They really shouldn't be pitted against each other. They have some similarities but typically EDI is intended for bulk data transfers where a Web API is more suited for smaller amounts of data, like one record per request/response. Sure, an API can do lists but compared to an EDI, the file can handle a lot more records.
*EDIT* Typically, EDI is good for a once daily update where an API can handle the incremental changes that occur throughout the day.
We probably do that but EDI is the only automated solution available aside from scraping their web site. Depending on the time of the month the request can be small or several account numbers at once.
We try and keep track of when the last time we made a request for a particular account number and only request it once a month but there's days where there is a lot of account numbers and there are days where there are none.
The amount of the request may be small but the files coming back would be usage data and 15 minute interval data.
An api can still do that. I do this all the time with json/http apis: a bulk_upsert endpoint and you just feed/stream a batch of objects. Never did a bulk_patch but the implementation is nearly the same.
If I cat all those patch objects to a file on a shared drive, knowing that at midnight UTC every day, it'll get picked up and applied, that's still an API, albeit a kinda janky transport layer.
I've never heard someone try to make the case that it's an API per-say. More like a data format, such as JSON, with prescribed elements, etc. What the other end-system does with that data is up to them... and not all data is intended for pure automated programatic consumption (ie. invoices, etc).
The main issue with EDI is your industry either has embraced EDI or it hasn't... making it really difficult to use EDI if only a small subset of your manufacturers/vendors also support EDI. Typically organizations these days will support a REST API instead of EDI, which obviously requires quite a lot of custom integration work (even if using generation tools like swagger/openapi).