These technologies are fascinating and make good sense for some APIs for sure. But if I look at our APIs, and I don't think we're unusual, they characteristical

These technologies are fascinating and make good sense for some APIs for sure. But if I look at our APIs, and I don't think we're unusual, they characteristically are not "fire and forget". Instead, the API call actually returns some data in the API response! Even for POST /widgets, I want to pass back an identifier for the just created widget, not a 200 code that means "request accepted and queued but no data available right now". The uses for APIs that don't return data seem pretty limited in our realm (SaaS). One example is handling incoming notifications/webhooks from other systems. By their nature these are asynchronous and the caller (the external system) does not usually expect a meaningful response, so for sure we can use SQS to buffer the incoming API calls. But for the APIs that we offer, virtually all of them have an online response. In my experience this is not an unusual pattern (for SaaS APIs anyway). I feel that these technologies are somewhat biased towards super scale systems that are highly decoupled and asynchronous - perhaps the sort of systems that Amazon are used to dealing with in-house - rather than simple old business systems.