Ricky Moorhouse

API failure stories and what they taught me

Tue, 06 Oct 2026 21:25:00 +0100

Four generalised API failure stories about versioning, migration testing, sensitive data, and authorisation, with practical lessons for preventing them.

Netherlands 2026

Sat, 01 Aug 2026 00:00:00 +0000

Netherlands 2026

31 Jul - Folkestone
1 Aug - Doorn
3 Aug - Utrechtse Heuvelrug National Park
4 Aug - Utrecht
5 Aug - 📷 Zaanse Schans
6-7 Aug - Amsterdam
8 Aug - 📷 Kinderdijk
9 Aug - Henschotermeer
10 Aug - Wijk bij Duurstede
11 Aug - Calais

GitOps Deployment of API Connect

Sat, 25 Jul 2026 00:00:00 +0000

An overview of how we automate API Connect deployments with GitOps

Everything as code

Sun, 19 Jul 2026 00:00:00 +0000

Version everything - getting into the habit of treating everything as code gives you an easy way back, tracking and a review process built in.

Why Human Thinking Still Matters

Mon, 06 Jul 2026 17:06:00 +0000

We're building tools to save time, yet we often find ourselves with less time to think about why we're building them. A reflection on reclaiming the "messy" human part of the development process in the age of AI.

Machine-readable?

Sun, 28 Jun 2026 10:31:11 +0000

Applying metadata standards and formats to improve the readability of my blog for machines of different types.

MCP Ponderings

Sun, 21 Jun 2026 00:00:00 +0000

Some of my thoughts around MCP and how we can use it safely.

Securing Sensitive Payload Logging in API Connect

Fri, 22 May 2026 00:00:00 +0000

Overview of ways to handle sensitive data payloads within API Connect and controlling where that data ends up.

Cheriton Circular

Mon, 04 May 2026 00:00:00 +0000

Short circular walk around Cheriton with beautiful views around the area.

API Versioning is a Contract Commitment, not a Technical Choice

Mon, 13 Apr 2026 00:00:00 +0000

Teams spend a lot of energy arguing about whether to put the version in the URL, a header, or a query parameter. That debate usually misses the point. The real question is: what is your change management discipline, and how do you protect consumers from breaking changes?

Taking a step up from the versioning question - how are you managing changes to your API contract? Ideally this would be transparent to consumers unless there is something they are looking to take advantage of in the new changes. If your API is designed well it can abstract any internal requirements and technical limitations from your clients such that you can update the implementation internally and their applications will continue to operate without even needing to know about it.