How should we build the APIs of tomorrow?
A few ideas to put out there:<p>1. Emphasize synchronization over imperative API calls. <i>Imperative APIs encourage data silos.</i> They are the underlying technical part of the problem that Zapier and ITTT try to solve. See [0] and [1] for some ideas.<p>2. Allow users to submit &quot;agents&quot; rather than &quot;requests.&quot; An agent is a small program given extremely limited resources (limited process&#x2F;memory&#x2F;runtime budget) that you can safely run on your server. It is a possible answer to many of the standards&#x2F;protocols that wouldn&#x27;t exist if frontends were running on the same machines as backends. [2]<p>3. Emphasize composition over integration. Functions compose (nest, recurse). Event emitters don&#x27;t. As long as APIs are built to be integrated rather than composed, making them work together is a full-time or full-company job (eg. Zapier).<p>4. Make things immutable. Immutability allows APIs to &quot;play&quot; with one another without fear of setting off the nukes (ie. side effects). It&#x27;s possible that this approach would make it so that integrating two APIs becomes a job for ML&#x2F;AI rather than humans.<p>[0] <a href="https:&#x2F;&#x2F;github.com&#x2F;braid-work&#x2F;braid-spec" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;braid-work&#x2F;braid-spec</a><p>[1] <a href="https:&#x2F;&#x2F;writings.quilt.org&#x2F;2014&#x2F;05&#x2F;12&#x2F;distributed-systems-and-the-end-of-the-api&#x2F;" rel="nofollow">https:&#x2F;&#x2F;writings.quilt.org&#x2F;2014&#x2F;05&#x2F;12&#x2F;distributed-systems-an...</a><p>[2] <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=23900749" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=23900749</a>