<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
    <title>Andrew Lilley Brinker - API Design</title>
    <subtitle>I work on software security at MITRE, including serving as amember of the OmniBOR Working Group, where I lead development of the Rustimplementation, and as the project manager for Hipcheck, a tool forautomated supply chain risk assessment of software packages.
</subtitle>
    <link rel="self" type="application/atom+xml" href="https://www.alilleybrinker.com/topics/api-design/atom.xml"/>
    <link rel="alternate" type="text/html" href="https://www.alilleybrinker.com"/>
    <generator uri="https://www.getzola.org/">Zola</generator>
    <updated>2024-04-04T00:00:00+00:00</updated>
    <id>https://www.alilleybrinker.com/topics/api-design/atom.xml</id>
    <entry xml:lang="en">
        <title>Softlocking APIs</title>
        <published>2024-04-04T00:00:00+00:00</published>
        <updated>2024-04-04T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Andrew Lilley Brinker
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://www.alilleybrinker.com/blog/softlocking-apis/"/>
        <id>https://www.alilleybrinker.com/blog/softlocking-apis/</id>
        
        <summary type="html">&lt;p&gt;We can learn from case studies of APIs forever trapped by past decisions. Just
like a video game can softlock and become impossible to progress, so too can
APIs become softlocked by technical and social commitments.&lt;&#x2F;p&gt;</summary>
        
    </entry>
</feed>
