<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>API on Ricky Moorhouse</title>
    <link>https://rickymoorhouse.uk/tags/api/</link>
    <description>Recent content in API on Ricky Moorhouse</description>
    <generator>Hugo</generator>
    <language>en-gb</language>
    <lastBuildDate>Mon, 13 Apr 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://rickymoorhouse.uk/tags/api/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>API Versioning is a Contract Commitment, not a Technical Choice</title>
      <link>https://rickymoorhouse.uk/blog/2026/api-versioning-is-a-contract-commitment-not-a-technical-choice/</link>
      <pubDate>Mon, 13 Apr 2026 00:00:00 +0000</pubDate>
      <guid>https://rickymoorhouse.uk/blog/2026/api-versioning-is-a-contract-commitment-not-a-technical-choice/</guid>
      <description>&lt;p&gt;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?&lt;/p&gt;&#xA;&lt;p&gt;&lt;img src=&#34;https://rickymoorhouse.uk/blog/2026/api-versioning-is-a-contract-commitment-not-a-technical-choice/windswept.jpeg&#34; alt=&#34;Sand in the wind, Witterings&#34;&gt;&lt;/p&gt;&#xA;&lt;p&gt;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.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Observability as a design requirement</title>
      <link>https://rickymoorhouse.uk/blog/2026/observability-as-a-design-requirement/</link>
      <pubDate>Sat, 28 Mar 2026 00:00:00 +0000</pubDate>
      <guid>https://rickymoorhouse.uk/blog/2026/observability-as-a-design-requirement/</guid>
      <description>Observability is a design decision, not an afterthought. From the platform team to API consumers to AI agents, knowing what is happening across your API — and building that in from the start — is what gives you confidence when things go wrong in production.</description>
    </item>
    <item>
      <title>Designing for Multi-Region API Deployments</title>
      <link>https://rickymoorhouse.uk/blog/2026/designing-for-multi-region-api-deployments/</link>
      <pubDate>Sat, 14 Mar 2026 00:00:00 +0000</pubDate>
      <guid>https://rickymoorhouse.uk/blog/2026/designing-for-multi-region-api-deployments/</guid>
      <description>A practical guide to designing multi-region API deployments - covering data consistency, auth dependencies, traffic routing, and failure modes, with real-world lessons from IBM API Connect SaaS.</description>
    </item>
  </channel>
</rss>
