How should we build the APIs of tomorrow? – Increment: APIs

When I first started coding in the mid-to-late 2000s, REST APIs were all the rage. A few years earlier Roy Fielding had published his popular dissertation on designing network-based architecture, which caught on quickly, and rightfully so: At its core, it encouraged the building of uniform, shared interfaces to reduce complexity and make interfaces simpler. The industry was rapidly moving from SOAP to REST, as the latter made it feel more natural for users to compose the flows they needed for their specific behavior. REST worked amazingly well—and still does—for predominantly server-to-server flows, which were almost the entire internet at the time. Frameworks like Rails and Django made it possible to build a REST API in minutes, dozens of HTTP libraries were developed to interact over the network in just a few lines of code, and software like curl made it easy to test an API in seconds. Since then, the application landscape has changed dramatically which in turn has started to impact

When I first started coding in the mid-to-late 2000s, REST APIs were all the rage. A few years earlier Roy Fielding had published his popular dissertation on designing network-based architecture, which caught on quickly, and rightfully so: At its core, it encouraged the building of uniform, shared interfaces to reduce complexity and make interfaces simpler. The industry was rapidly moving from SOAP to REST, as the latter made it feel more natural for users to compose the flows they needed for their specific behavior. REST worked amazingly well—and still does—for predominantly server-to-server