API Developer Weekly Newsletter
Hundreds if not thousand of websites talk about APIs, I rely on James Higginbotham’s newsletter to stay up to date about what is happening in the API space thanks to his weekly selection of great posts.
API Handyman wouldn’t exist without the API Evangelist. It’s always a pleasure to read Kin Lane’s views on the API space. This site is a hyper-mega-huge source of information about ALL aspects of APIs from API definitions to monetization and governance and dozens of other topics.
I started this project with a simple API Design Guidelines list in mind and ended with a fully analyzed collection of API design guidelines. I created it for others but I use it myself too. When I wonder how to handle some API design matters, I select the related topic and read how others handle it. To be honest, it needs some refresh, it is a real pain to update and maintain and could be more user friendly; that’s on my todo list.
Ever wanted to quickly find, extract or modify data coming from some JSON documents on the command line? JQ is the tool you’re looking for. I use it every time I need to tranform, modify or extract some properties from an API’s response or analyze OpenAPI specification JSON files during my API reviews.
Net API Events
Thanks to Matthew Reinbold’s Net API events, I stay up to date regarding upcoming API related conferences.
Net API Notes Newsletter
I always read Matthew Reinbold’s Net API Notes Newsletter with delight. It’s not just a bunck of links; every week Matthew actually writes a letter in which he shares his thoughts accompanied with links to relevant posts of the past week.
I built the OpenAPI map because I was constantly searching for “how do this with the OpenAPI spec” and also “but where is that thing” in the specification. Having the OpenAPI specification represented as a tree given essential information and quick access to source documentation of each element saved me countless time.
Without the OpenAPI Specification (fka. Swagger Specification), my job would be a total nightmare. It is a machine readable API description format that I use when I design APIs, when reviewing API designs, documentating APIs, checking that implementation conforms to design and build implementation.
I use Spectral while designing APIs and during API design reviews. It is a JSON/YAML linter with built-in support for OpenAPI 2 and 3 (and also AsyncAPI). I use it to check that API designs conform to my guidelines and also to spot unusual design patterns that needs to be discussed with the people in charge of the API. It really speeds up my reviews and help me avoid oversights.
I use Spectral while designing APIs and during API design reviews. It is API an design UI that supports OpenAPI 2 and 3. It comes with a totally awesome Spectral (OpenAPI linter) integration. The UI does not cover all features of the OpenAPI formats, but it’s not a problem for most users: this is the most complete and the best tool of his kind. And I love being able to switch between UI and code views (this also helps to do what you can’t do with the UI).
If you wonder what means a 418 HTTP status code or which RFC defines the txn JWT claim, Web concepts is what you’re looking for. I just stopped doing HTTP/web/RFC related search, I now always check Erik Wilde’s web concepts first and usually find what I’m looking for instantly. Icing on the cake, all data is also available in JSON format.