donzog

We do have a Registered Trademark. Thank you for the reply.

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.

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

Are they still in business? I heard they fired lots of developers, bless them.

Go with Stedi.com.au instead, it's lighter. Longtime EdiFabric developer. Always had a plan.

+1 haha, indeed.

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.

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.

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

"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 :)

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.

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

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

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

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

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.

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.

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.

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.

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

How is the experience any better? EdiFabric is a library that you install locally, not a web API. As far as I'm aware, tsedi can't generate acknowledgments, can't import SEF, can't parse healthcare X12, can't parse any EDI format beyond some X12, can't split files, can't process large data, can't have custom validation, etc. In other words, it's a very immature and amateurish product. BTW how are you cornered into using EdiFabric? Anything specific to share?