EDI vs. API

https://support.edifabric.com/hc/en-us/articles/6738567109277-EDI-vs-API

by donzog • 4 years ago

104 97 4 years ago

support.edifabric.com

Alupis• 4 years ago

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• 4 years ago

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

SystemOut• 4 years ago

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.

themerone• 4 years ago

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.

P5fRxh5kUvp2th• 4 years ago

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.

sleepymoose• 4 years ago

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.

lksh_dev• 4 years ago

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• 4 years ago

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.

jetti• 4 years ago

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.

Octoth0rpe• 4 years ago

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• 4 years ago

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

duxup• 4 years ago

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

therein2• 4 years ago

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.

nico• 4 years ago

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

jen20• 4 years ago

The WSDL part has somewhat been replaced by OpenAPI.

masa331• 4 years ago

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

soco2• 4 years ago

And then comes OData...

rs999gti• 4 years ago

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• 4 years ago

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

arpinum• 4 years ago

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.

donzog19• 4 years ago

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

devnull255• 4 years ago

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.

donzog19• 4 years ago

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

jrochkind1• 4 years ago

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.

danielmarkbruce3• 4 years ago

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

to11mtm• 4 years ago

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_White2• 4 years ago

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.

NonNefarious• 4 years ago

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

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

donzog19• 4 years ago

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.

nightski3• 4 years ago

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.

calvinmorrison• 4 years ago

There's no requirement for API's to only accept JSON. I mean we had SOAP (bleck)

nightski3• 4 years ago

I agree, but in the article they define an API as one accepting JSON. So I was just going with the conventions they were using.

cestith• 4 years ago

JSON, YAML, XML, and several other formats are basically various failed attempts to reimplement the utility and simplicity of s-expressions.

peheje2• 4 years ago

You can put anything in body, doesn't have to be json format. Could be csv. Base64 or binary etc.

Existenceblinks2• 4 years ago

If we are talking about HTTP here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Co...

donzog19• 4 years ago

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.

hk13374• 4 years ago

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.

peheje2• 4 years ago

api can receive files, what am i missing

hk13374• 4 years ago

The bulk data part. EDI would likely be more useful when you want updates on 100,000+ records at once, each record with multiple fields.

themadturk2• 4 years ago

Tell that to the EDI customers I work with, who either dribble out (or receive) data almost constantly, or dump thousands of files on us at once.

hk13374• 4 years ago

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.

IncRnd• 4 years ago

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.

donzog19• 4 years ago

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

henning• 4 years ago

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.

donzog19• 4 years ago

+1 haha, indeed.

dahfizz3• 4 years ago

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.

hk13374• 4 years ago

I am sick of people conflating "API" with REST or HTTP

That bugs me too. lol. I have included in interviews as more of a fun question and conversation on what is an API.

extragood• 4 years ago

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

PaulDavisThe1st• 4 years ago

I am sick of people conflating "API" with REST or HTTP. Applications had Programmable Interfaces before HTTP even existed.

I am sick of people conflating "Programming" with "Programmable". The interface isn't programmable, it exists to program applications.

So there.

fshr• 4 years ago

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.

dahfizz3• 4 years ago

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.

donzog19• 4 years ago

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.

kazinator• 4 years ago

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.

JaggedJax3• 4 years ago

All EDI is an API (of a very specific and defined type).

All API are not EDI.

Therefore API !== EDI

All couches are furniture, but couches are not "equivalent" to furniture.

floathub2• 4 years ago

All of Alma Cogan is dead, but only some of the class of dead people are Alma Cogan.

JaggedJax3• 4 years ago

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.

donzog19• 4 years ago

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

_1tan• 4 years ago

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.

donzog19• 4 years ago

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.

projektfu• 4 years ago

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.

slively• 4 years ago

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.

moistly• 4 years ago

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.

femto113• 4 years ago

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.

warpspin• 4 years ago

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.

raydiatian2• 4 years ago

Go with Stedi.com instead.

Longtime EdiFabric user. Never was a fan.

adriand• 4 years ago

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.

donzog19• 4 years ago

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

donzog19• 4 years ago

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

raydiatian2• 4 years ago

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.

pleb_nz• 4 years ago

I would have said an EDI is a type of API.

omgitstom• 4 years ago

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)

EDI vs. API

Related Stories