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".
Re:EDI vs. API
by danielmarkbruce on Wednesday September 14, 2022 @10:50AM
(#32838047)
"Web API"
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.