[svapnil]

Thanks for sharing habitue

It's true that REST APIs operate under the assumption of processing at request time, while not the case with files. That's what makes Bank REST APIs so tricky - processing doesn't ever actually occur at request time.

There are so many crazy formats that are supported. Simpler is better imo

[nicholasjarnold]

> That's what makes Bank REST APIs so tricky - processing doesn't ever actually occur at request time.

HTTP has provisions to enable async semantics between the client and the server. I would always advocate for teams to return 202 Accepted responses with a Location header containing the absolute or relative path to an endpoint that can be interrogated for status of the underlying async operation. This can work fine for lower-scale services (or even higher scale services with rate limits enforced at gateway). You POST'd a payment. You get 202 Accepted with some Location value like (simplified) `/payments/<identifier>` for which GET can be used to retrieve current status (e.g. pending, failed, committed, etc).

If a polling model is not desirable you can also use webhooks and inform the caller whenever a given task is finished.

Both of these strategies work fairly well in practice in my experience. However, I Must agree that simply dropping a big file off at an sFTP share and moving on with life is certainly "easier" from the client perspective. But...do you then roll your own mechanism for checking status? Why not just use HTTP semantics that exist already?