EDI vs. API
support.edifabric.com
support.edifabric.com
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).
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.
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.
EDI = data, API = functionality. They can work in tandem, but don't have to.
you might as well say FTP is an API. In the most technical sense, sure.
(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).
But the whole debate is a little pedantic for me. Just need to get it working ...
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.
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.
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.
This is more apt to call a protocol than an API. An API could conform to this protocol though, in a manner of speaking.
Not in most logistics, purchase orders, and invoicing business cases. We have offered APIs, but most orgs want to do EDI.
We have significant volume still going through EDI that we have to keep it running, no matter how badly we want to stop maintaining it.
Even worse, even though there is X12 standard some orgs still want customizations.
EDI and ACH files need to be deprecated but money talks.
If you know, you know!!!!
Ha, ha, this gave me flashbacks to reading the X12 834 spec for healthcare transactions when it first came out.
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.
No idea why this is on HN other than seeing an EDI company fumble a marketing article so badly while trying to stay relevant.
I don't miss working with EDI.
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.
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.
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".
- 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'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.
Otherwise you're on the money. This whole "debate" is dumb.
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.
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.
That bugs me too. lol. I have included in interviews as more of a fun question and conversation on what is an API.
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.
I am sick of people conflating "Programming" with "Programmable". The interface isn't programmable, it exists to program applications.
So there.
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 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.
All API are not EDI.
Therefore API !== EDI
All couches are furniture, but couches are not "equivalent" to furniture.
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.
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)
Longtime EdiFabric user. Never was a fan.
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.
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.
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.
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.
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.
*EDIT* Typically, EDI is good for a once daily update where an API can handle the incremental changes that occur throughout the day.
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.
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.