[nightski]

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.

[peheje]

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

[calvinmorrison]

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

[nightski]

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.

[soco]

If they built a strawman argument we don't have to accept it.

[nightski]

Agreed that is what I was trying to say in my comment haha. I didn't like the article.

[robertlagrant]

But then it's not a huge technical impediment to EDI. It's just what some article said.

[cestith]

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

[donzog]

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.

[Existenceblinks]

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