I can't remember a time that I didn't hear API and immediately think of Postman.  Specifically REST (I'm still trying to wrap my mind around Postman now supporting GraphQL).  Seems like everything in the world has a REST API now, whether it's oData or HAL or some bizarre architecture or even just some hodge podge duct taped mess.  And in some ways that's great- but in other ways, this complicates the transmission of data and the design of services built on that transmission.  Here are a couple of caveats that I've learned the hard way :

• Streaming data/IoT.  Without a webhook, there's simply no way to compile anything meaningful on the client end.  This isn't a failing of the REST standard itself, but more of the client implementation of it.  Making incremental requests at a schedule sufficient to compile something meaningful from the stream is just simply not a good method, regardless of whether that's 86,400 requests or 3600 per day.  A REST proxy head atop a Kafka stream is a great example of this.  Great idea in theory- and it certainly beats not having access to that data stream at all, but it's a poor approximation of the stream itself.  There's just simply no great way right now for companies to share streaming data; but pub-sub models get us closer than anything else.
   
• Chunking out a monolith: whether that's a round-trip microservice (i.e. an API call that makes another API call) or sequentially dependent calls all from the same client.  It's an absolute wasteland to try and troubleshoot those or build error handling on either client or server side.  Just not an approach you want to take for mission critical tasks.
   
• ERPs.  Dear God, I can't wait for someone to invent a graph-native ERP.  If you're unfamiliar with these databases, they are the very epitome of 'relational'.  Every single table is interconnected to potentially dozens or even hundreds of other tables through a labyrinthine network of foreign keys and integer:code cross references.  There's simply no way to construct a REST API that can handle that complexity well (SAP tries, and it's certainly usable but holy shit it's a mess).  The sooner we pivot to GraphQL for these monsters, the better.  Although that's kind of a moot point as there's probably a total of 5 data engineers in the world who understand financial/accounting transactional data systems.