[hk1337]

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.

[themadturk]

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.

[hk1337]

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.

[peheje]

api can receive files, what am i missing

[hk1337]

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.

[kortex]

An api can still do that. I do this all the time with json/http apis: a bulk_upsert endpoint and you just feed/stream a batch of objects. Never did a bulk_patch but the implementation is nearly the same.

If I cat all those patch objects to a file on a shared drive, knowing that at midnight UTC every day, it'll get picked up and applied, that's still an API, albeit a kinda janky transport layer.