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.
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".
No idea why this is on HN other than seeing an EDI company fumble a marketing article so badly while trying to stay relevant.
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.
- 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.
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.
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.
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.
I don't miss working with EDI.
(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).
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.
Otherwise you're on the money. This whole "debate" is dumb.
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).