If you want to get into API design-first, but awkwardly already have a bunch of APIs with no OpenAPI, use a HTTP proxy like Akita to create OpenAPI from your HTTP traffic!

Existing tooling developers have created their own approaches to bundling JSON Schema and OpenAPI documents, but that can lead to errors. Bundling is now standardised.

What happens in your client application when an API error pops up beyond the common cases of Logged Out, Not Found, etc.? Do you vomit random API error codes and exception class names all over your end users screens, pointlessly confusing the hell out of them?

Sometimes you see people complaining about OpenAPI (formerly Swagger), saying they don't want to to write out a whole bunch of YAML/JSON by hand. Other than disability, there's no reason you need to do that, and there hasn't be for a long time. Whether you pick code-first or design-first, you've got some options.

JSON Schema and OpenAPI will no longer have minor differences in the schema object, but will finally be compatible from OpenAPI v3.1.

The Ketting library is a generic hypermedia client written in JavaScript. It supports an opinionated set of modern features REST services might have, including HAL, JSON:API, Web Linking (HTTP Link Header) and HTML5 links. Ketting v5.0 just released with support for Siren and other neat new features.

Create API style guides using linting tools for any API paradigm. Avoid "API Governance" teams sitting there reviewing every single API change that comes through, and automate that menial task away to the bots.

What's the difference between a callback and a webhook, and which does OpenAPI support? Read on to find out the current status and upcoming changes for asynchronous and two-way APIs.

With API descriptions rising in popularity, the main question I hear folks asking about is "API Design-first" or "code-first". This is a bit of a misleading question because these are not two unique things, there are a few variants.

Bringing nuance to the polarized subject of caching in GraphQL.

Got some code that talks to a Web API and want to make sure it works properly? Here's a bunch of options you can use to mock external dependencies.

Why waste a bunch of time duplicating validation rules in your application code and API description documents, then waste even more time trying to make sure these two disparate sources match up? Save a bunch of time and avoid mismatch bugs by using your API description as production code, so you have one source of truth, and your existing test suite can do the job of making sure things work.

A modern day look at the Richardson Maturity model, and insight into how the various layers of abstraction REST provides can help API Developers working in HTTP for various scenarios.

It all comes down to what you can protect and where you redirect.

Dealing with the Happy Path™ in an API is pretty easy, but creating useful error messages can be tricky at first.

Specifications, Descriptions, Definitions, Spec Files, Contracts, ugh… they’re the same thing!

Another guest post from our friend Darrel Miller, this time explaining caching.

Split your AsyncAPI documents into multiple files with $ref.

Written by Darrel Miller, on his blog Bizcoder.com

In a system-oriented architecture, it is crucial to communicate with other systems, sometimes synchronously. Broker patterns, proxies, etc., or even just a remote procedure being triggered synchronously, like confirming an email has been sent successfully.

One source of truth: API Specifications, and get docs, mocks, testing, and more.

But there are a few objectively terrible ways to handle it.

The last year has involved a lot of teaching engineers how to use OpenAPI, with the day job growing from a startup to a sizeable…

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…

This article provides a decision flow diagram for selecting the “approach” to use for your next API.

Learn what rate limiting is all about, and how you can train your HTTP client code to handle being limited.

API Evolution is making a comeback these days, and REST advocates have been begging folks to use it for years. Let's learn how.

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…

Let's learn a bit more about JSON HyperSchema, building on the foundation in part one, with resource representations, arbitrary request bodies, HTTP headers, and HTTP methods.

This article is going to explain OpenAPI and JSON Schema divergence, which I’ve been calling the subset/superset/sideset problem. There are some plans to fix it, but they're a way off.

So you are using design-first for new APIs, but what about old APIs? Play catchup with a few sneaky methods.

These days type systems are all the rage in APIs, so lets see how HTTP APIs can use JSON Schema for client-side validation.

Every API is following some sort of paradigm, whether it knows it or not. Learn the differences, for when you talk to other APIs.

JSON Hyper-Schema is a format for describing an API. You can automate a lot with a document that describes your API.

We discovered some fairly interesting behaviors in Net::HTTP recently, and figured we better share them.

We've been talking a lot about the importance of documentation and API descriptions, Now let’s look at how we can ensure those descriptions are actually telling the truth!

If you absolutely positively have to use JSON:API for your API, here's how to make it work well for you.

JSON:API has been one of the most popular standards for API development for a while now. It was conceived in 2013, battled through some...

Caching is a huge topic, and there’s a lot of different types of caching. No one type of cache is going to suite all needs and cover…

But there are a few objectively terrible ways to handle it.

What is the difference between them?

Continuing on the topic of contracts — metadata that describes your data — it makes sense to see what easy early wins you can make from…

When building and maintaining a Web API, it's surprisingly common for the "I" (interface) part to be overlooked. Often new functionality is…

People seem to be moaning about JSON when they really just are upset with unspecified data.

With endpoint-based APIs (REST, RESTish, SOAP, RPC, AJAX-ish junk, etc.) you get to choose if you want increased likelihood of network…

Do you like the look of GraphQL, but have an existing REST/RPC API that you don’t want to ditch? Here's how to get those benefits without rewriting it.

Outlining the approach the two API paradigms take to caching.

Learn how an API can become a state machine, with different actions appearing for resources in different states.

An objective overview and comparison of REST and GraphQL, despite it being rather strange to try and compare a paradigm and an implementation.