Co-founder of APIs You Won't Hate, consultant/writer on all things API, working on green/climate tech, and restoring nautral habitats as co-founder of @ProtectEarthUK.
Another guest post from our friend Darrel Miller. This is my attempt to make the HTTPbis caching rules more accessible and hopefully shine a light on how powerful HTTP caching can be. I’ve been working on a Pluralsight course that talks about how to use the Microsoft HttpClient library.
book
Designing the world's most beautiful API is only half the story, somebody needs to interact with it!
Written by Fran Méndez and re-posted here with permission. A recurring question that I get very often is: "how do I organize my AsyncAPI documents?". Also, the related one: "I have two services, a publisher and a consumer, should I define both in the same AsyncAPI document?
Written by Darrel Miller, on his blog Bizcoder.com. This article makes a case for trying to acoid batch requests (or compound documents, included resources, etc) in situations that make interactions slower. HTTP/2 is here, and we need tos foip some of the ways we think on our head!
books
Everyone and their dog wants an API, so you should probably learn how to build them.
In a system-oriented architecture, it is crucial to communicate with other systems. In an ideal world each service knows enough information to satisfy its clients, but often there are unfortunate requirements for data to be fetched on the fly. Broker patterns, proxies, etc., or even just a remote procedure being
Is your API working right now? It can be a tough question to answer. A lot of monitoring tools are out there, like Prometheus which can track all sorts of metrics, but that assumes metrics are being sent to it which let you know there’s a problem. Maybe NewRelic
A regular question on Twitter, at WeWork, and in the APIs You Won’t Hate Slack community, is: "What standard should my API follow? Should it be JSON API or something else?” At which point a bunch of people usually start discussing things like OpenAPI and/or JSON Schema.
Update: I spent a lot of time duct-taping and glueing crap together to get a coherent workflow together because tooling at the time was rather lacking for API Design-First. Most of this experience has gone into making Stoplight Studio and Stoplight Platform awesome, covering all the docs, mocks, linting, style
Guest post from Aaron Hedges. In the last two JSON-Hyper Schema articles (Getting Started — Part One and Part Two), we covered the basics: * Basic Links * Request and response bodies * Request and response headers * HTTP methods But while working with JSON Hyper-Schema I have discovered a couple of common API patterns
Update (2019-10-04): When I left WeWork I left Speccy with a few colleagues, who have thankfully done a lot of maintainance work. If you like the idea of Speccy but want more power, use Spectral by Stoplight. It has a bunch of developers and community contributors regularly adding amazing features,
Deprecation, is the art of telling people to stop using that thing, because that thing is probably going away at some point. Even if there are no solid plans to delete the thing entirely, the thing might be deprecated just because it sucks to work with, but usually it'