[Alupis]

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).

[couchand]

I've never seen an EDI implementation that required nothing custom. The claim is oft-repeated but based on little substance.

[themerone]

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.

[pdimitar]

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.

[donzog]

I still work in the EDI-parser software but retiring to the mountain has never been more appealing.

[SystemOut]

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.

[andrew_]

Worked in Logistics and can confirm. AT&T had a dozen different data formats for the same data across their network of warehouses.

[themadturk]

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.

[sleepymoose]

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.

[jetti]

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.

[donzog]

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.

[P5fRxh5kUvp2th]

that's still not API though.

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.

[lksh_dev]

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.

[WesleyJohnson]

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.

[Brian_K_White]

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.

[masa331]

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

[jrochkind1]

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.

[danielmarkbruce]

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...).

[donzog]

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.

[danielmarkbruce]

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.

[donzog]

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".

[danielmarkbruce]

"Web API"

[arpinum]

I have not heard this claim either and I work in the EDI space.

No idea why this is on HN other than seeing an EDI company fumble a marketing article so badly while trying to stay relevant.

[donzog]

There is always the first time. Much like we created the first EDI API https://edination.com/

[duxup]

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 ...

[therein]

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.

[dahfizz]

> 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.

[therein]

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.

[miffy900]

> 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.

[to11mtm]

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).

[Brian_K_White]

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.

[rs999gti]

> Typically organizations these days will support a REST API instead of EDI

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.

[artistminute]

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

[donzog]

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.

[chevman]

When all else fails, shove it in 'ZZ mutually defined' baby!

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.

[donzog]

Ha, ha, can't believe DC/Marvel haven't invented the ZZ-man/woman already

[devnull255]

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 don't miss working with EDI.

[donzog]

But this is not EDI's fault, it's the power-crazed companies and their management that bastardize EDI. Because they can.

[Octoth0rpe]

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)

[chrisweekly]

+1 helpful comment

(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).

[donzog]

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.

[nico]

Sounds a lot like SOAP/WSDLs, which ended up being mostly replaced by REST.

[jen20]

The WSDL part has somewhat been replaced by OpenAPI.

[donzog]

+1 At least that's what we built OpenEDI on top of - https://github.com/EdiNation/OpenEDI-Specification

[foobarian]

[GraphQL has entered the room]

[Existenceblinks]

[No one else is here]

[NonNefarious]

The term is "per se," by the way.

Otherwise you're on the money. This whole "debate" is dumb.

[soco]

And then comes OData...