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'
This article provides a decision flow diagram for selecting the "approach” to use for your next API. To oversimplify things a bit, it’s reasonably fair to say that all APIs conform to a paradigm: "RPC”, "REST”, or "query language”. These are general approaches to building
Something API clients (applications talking to APIs) are not often aware of, but run into often, is rate limiting; the API telling you to calm down a bit, and slow down how many requests are being made in a certain timeframe. The most basic rate limiting strategy is often "
There are a lot of pros and cons to various approaches to API versioning, but that has been covered in depth before in API Versioning Has No "Right" Way. API evolution is making a comeback these days with GraphQL and gRPC advocates shouting about it. Whatever API paradigm
Part of my day job is trying to get folks to write API documentation, so the hordes of new developers joining the company on a weekly basis are not stuck trying guess at contracts by poking around years old code. Convincing API developers to take the time to write specs