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