publish leonard richardson's interview

2 files changed, 199 insertions, 0 deletions

diff --git a/www/content/essays/_index.md b/www/content/essays/_index.md
index 8ab0e734..8fc39afb 100644
--- a/www/content/essays/_index.md
+++ b/www/content/essays/_index.md
@@ -75,6 +75,7 @@ page_template = "essay.html"
 * [Makinde Adeagbo](@/essays/interviews/makinde_adeagbo.md), creator of [Primer](https://www.youtube.com/watch?v=wHlyLEPtL9o)
 * [Chris Wanstrath aka @defunkt](@/essays/interviews/chris_wanstrath.md), creator of [pjax](https://github.com/defunkt/jquery-pjax)
 * [Mike Amundsen](@/essays/interviews/mike_amundsen.md), author of [RESTful Web APIs](http://restfulwebapis.com/)
+* [Leonard Richardson](@/essays/interviews/leonard_richardson.md), creator of the [RMM](https://en.wikipedia.org/wiki/Richardson_Maturity_Model)
 
 ## Banners
 <div style="text-align: center;margin:32px">
diff --git a/www/content/essays/interviews/leonard_richardson.md b/www/content/essays/interviews/leonard_richardson.md
new file mode 100644
index 00000000..aa7b8366
--- /dev/null
+++ b/www/content/essays/interviews/leonard_richardson.md
@@ -0,0 +1,198 @@
++++
+title = "An interview with Leonard Richardson"
+description = """\
+  In this interview, Leonard Richardson, creator of the Richardson Maturity Model for RESTful web services discusses\
+  the history of REST, interoperability in APIs and his impression of newer approaches such as GraphQL."""
+date = 2025-02-19
+updated = 2025-02-19
+authors = ["Carson Gross"]
+[taxonomies]
+tag = ["posts"]
++++
+
+Leonard Richardson is a long time programmer and author and was the creator of what came to be termed the Richardson
+Maturity
+Model ([https://en.wikipedia.org/wiki/Richardson\_Maturity\_Model](https://en.wikipedia.org/wiki/Richardson_Maturity_Model)),
+a system for classifying Web APIs in terms of their adherence to REST. Here, Web APIs mean *data APIs*, that is data
+intended to be consumed by automated systems or code, rather than directly by a web client.
+
+The RMM consists of four levels:
+
+* Level 0 \- The Swamp of POX (Plain old XML)
+* Level 1 \- The appropriate use of resource-based URLs
+* Level 2 \- The appropriate use of HTTP Methods
+* Level 3 \- Hypermedia Controls
+
+A Web API became more mature as it adopted these technologies and conventions.
+
+Leonard agreed to talk to me about the RMM and his experiences building Web software.
+
+**Question**: Can you give us some background about yourself and how you came into web programming? Did/do you consider
+yourself a hypermedia enthusiast?
+
+When I was in high school in the mid-1990s, I got very basic Internet access through BBSes. There were all these
+amazing, arcane protocols you had to learn to get around: FTP, Gopher, Archie, NNTP, et cetera. And then just as I went
+to college, the World Wide Web suddenly wiped out all of those domain-specific protocols. Within a couple of years we
+were using the Web technologies–URI, HTTP and HTML–for everything.
+
+My formative years as a developer happened against the background of the incredible power of those three core
+technologies. Everything was being built on top of the Web, and it basically worked and was a lot simpler than the old
+way.
+
+So yes, I am a hypermedia enthusiast, but it took me a really long time to understand the distinct advantages that come
+from the "hypermedia" part of the Web. And that came with an understanding of when those advantages are irrelevant or
+undesirable from a business standpoint.
+
+**Question**: Can you give us a brief history of early Web APIs? What was the origin story of the RMM?
+
+What we now call "web APIs" started as a reaction against SOAP, a technology from a time when corporate firewalls
+allowed HTTP connections (necessary to get work done) but blocked most other traffic (games?). SOAP let you serialize a
+procedure call into XML and invoke it over an HTTP connection, punching through the firewall. It was an extraordinarily
+heavyweight solution, using the exact same tools–XML and HTTP–you'd need to make a good lightweight solution.
+
+Now that I'm an old fogey, I can look back on SOAP and see the previous generation of old fogeys trying to make the
+1990s client-server paradigm work over the Internet. SOAP had a lot of mindshare for a while, but there were very few
+publicly deployed SOAP services. When you deploy a service on the public Internet, people expect to connect to it from a
+wide variety of programming languages and programming environments. SOAP wasn't cut out for that because it was so heavy
+and demanded so much tooling to compensate for its heaviness.
+
+Instead, developers picked and chose their designs from the core web technologies. Thanks to the dot-com boom, those
+technologies were understood by practicing developers and well supported by every major programming language.
+
+The RMM, as it's now called, was originally a heuristic I presented
+in [a talk in 2008](https://www.crummy.com/writing/speaking/2008-QCon/act3.html). [The first part of the talk](https://www.crummy.com/writing/speaking/2008-QCon/act1.html)
+goes over the early history I mentioned earlier,
+and [the second part](https://www.crummy.com/writing/speaking/2008-QCon/act2.html) talks about my first experience
+trying to sell hypermedia-based API design to an employer.
+
+I’d analyzed about a hundred web API designs for my book on REST and seen very strong groupings around the core web
+technologies. You'd see a lot of APIs that "got" URLs but didn't "get" HTTP. But you'd never see one where it happened
+the other way, an API that took advantage of the features of HTTP but didn't know what to do with URLs. If I had one
+insight here, it's that the URL is the most fundamental web technology. HTTP is a set of rules for efficiently dealing
+with URLs, and HTML (a.k.a. hypermedia) is a set of instructions for driving an HTTP client.
+
+**Question**: In “How Did REST come to mean the opposite of REST?” I assert that the term REST has nearly inverted in
+its meaning. In particular, I claim that most APIs stopped at “Level 2” of the RMM. Do you agree with these claims?
+
+Everyone understands URIs these days, and understanding HTTP is essential for performance reasons if nothing else. That
+gets you to level 2, and yes, there we have stayed. That's what I was getting at
+in [this interview from 2007](https://www.infoq.com/articles/richardson-ruby-restful-ws/), a year before I gave my
+famous talk:
+
+The big question in my mind is whether architectures consciously designed with REST in mind will “win” over
+architectures that are simple but only intermittently RESTful.
+
+You don't get a certificate signed by Roy Fielding for achieving level 3\. The reward for learning and applying the
+lesson of hypermedia is *interoperability*. Your users get the ability to use your system in ways you didn't anticipate,
+and they get to combine your system with their other systems.
+
+Interoperability is essential in a situation like the Web, where there are millions of server and client deployments,
+and a dozen major server implementations. (There are now only two major client implementations, but that's its own sad
+story.)
+
+For a long time I thought people just didn't get this and if I hammered on the technical advantages of hypermedia they'd
+come around. But we've been stuck at level 2 for more than half the lifetime of the Web. It's become clear to me that
+most situations aren't like the Web, and the advantages of hypermedia aren't relevant to most business models.
+
+**Question**: Level 3 style hypermedia controls never really took off in Web APIs. Why do you think that is?
+
+I don't do this for everything, but I am going to blame this one on capitalism.
+
+Almost all actually deployed web APIs are under the complete control of one company. They have one server implementation
+written by that company and one server deployment managed by that company. If the API has any official client
+implementations, those are also controlled by the company that owns the API. The fact that we say "the \[company\] API"
+is the opposite of interoperability.
+
+Users like interoperability, but vendors prefer lock-in. We see that in their behavior. Netflix was happy to provide a
+hypermedia API for their program data... until their streaming business became big enough. Once they were the dominant
+player and could dictate the terms of integration, Netflix shut down their API. Twitter used to cut off your API access
+if your client got too popular; then they banned third-party clients altogether.
+
+There are lots of APIs that consider interoperability a strong point, and many of them are oriented around hypermedia,
+but almost all of them live outside the space of commercial competition. In 2008 when I gave the "maturity heuristic"
+talk I was working on software development tools at Canonical, which is a for-profit company but heavily involved in
+open source development. We wanted lots of tools and programming environments to be able to talk to our API, but the API
+was a relatively small part of our process and we didn't have enough developers to manage a bunch of official clients. A
+hypermedia-based approach gave us a certain flexibility to change our API without breaking all the clients.
+
+After that I spent eight years working on ebook delivery in the US public library space, which is extremely fragmented
+in terms of IT management. In a nonprofit environment with lots of independent server deployments, hypermedia (in the
+form of the [OPDS](https://opds.io/) protocol) was a really easy
+pitch. [I gave a talk about that.](https://www.crummy.com/writing/speaking/2015-RESTFest/)
+
+To get the benefits of hypermedia you have to collaborate with other people in the same field, consider the entire
+problem space, and come up with a design that works for everyone. Who's going to go through all that work when the
+reward is “no vendor lock-in”? People who are not competing with their peers: scientists, librarians, and open source
+developers.
+
+It might or might not surprise you to learn that the library world is dominated by an antique protocol
+called [SIP](https://developers.exlibrisgroup.com/wp-content/uploads/2020/01/3M-Standard-Interchange-Protocol-Version-2.00.pdf). (
+Not the VoIP protocol, a different SIP.) SIP is what the self-checkout machine uses to record the fact that you borrowed
+the book. SIP first showed up in 1993, its design is distinctively non-RESTful, and in many ways it’s simply *bad*.
+Every library vendor has come up with their own level 2 "REST" protocol to do what SIP does. But none have succeeded in
+displacing SIP, because that awful old 1993 design provides something a vendor can't offer: interoperability between
+components from different
+vendors. [I gave a talk about that, too.](https://www.crummy.com/writing/speaking/2016-RESTFest/)
+
+**Question**: Do you think the move from XML to JSON as a format had any influence on how Web APIs evolved?
+
+Absolutely. Moving from XML to JSON replaced a document-centric design (more suitable for communications with a human at
+one end) with a data-centric design (more suitable for machine-to-machine communication). The cost was forgetting about
+hypermedia altogether.
+
+One thing about Martin's diagram that I think obscures more than it reveals is: he calls level 0 the "Swamp of POX".
+This makes it seem like the problem is (Plain Old) XML. Martin is actually talking about SOAP there. The big problem
+with SOAP services isn't XML (although they do have way too much XML), it's that they don't use URLs. A SOAP client puts
+all of the request information into an XML package and tunnels it through a single service endpoint. This makes SOAP
+opaque to the tools designed to manage and monitor and inspect HTTP traffic. This is by design, because the point of
+SOAP is to let you make RPC calls when your IT department has everything but port 80 locked down.
+
+Anyway, XML is great\! It's too verbose to make an efficient data representation format, but XML has namespaces, and
+through namespaces it has hypermedia controls (via XLink, XForms, XHTML, Atom, etc.). JSON has no hypermedia controls,
+and because it also has no namespaces, you can't add them after the fact.
+
+People started adopting JSON because they were tired of XML processing and excited about AJAX (in-browser HTTP clients
+driven by Javascript, for those who weren't there). But that initial decision started constraining decisions down the
+road.
+
+By 2011, all new web APIs were using a representation format with no hypermedia controls. You couldn't do a
+hypermedia-based design if you wanted to. Our technical language had lost the words. First you'd have to define a
+JSON-based media type that had hypermedia (like Siren), or namespaces (like JSON-LD).
+
+**Question**: What are your thoughts on GraphQL and other non-RESTful API technologies?
+
+With regard to non-RESTful API technologies in general, I would suggest that folks take a break
+from [chapter 5](https://ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm) of Roy Fielding's dissertation,
+and look at chapters [2](https://ics.uci.edu/~fielding/pubs/dissertation/net_app_arch.htm%20)
+and [4](https://ics.uci.edu/~fielding/pubs/dissertation/web_arch_domain.htm).
+
+Chapter 5 is where Fielding talks about the design of the Web, but Chapter 2 breaks down all of the possible good things
+you might want from a networked application architecture, only some of which apply to the Web. Chapter 4 explains the
+tradeoffs that were made when designing the Web, giving us some good things at the expense of others.
+
+Chapter 4 lists five main advantages of the Web: low entry-barrier, extensibility, distributed hypermedia, anarchic
+scalability, and independent deployment. REST is a really effective way of getting those advantages, but the advantages
+themselves are what you really want. If you can get them without the Web technologies, then all you've lost is the
+accumulated expertise that comes with those technologies (although that ain't nothing at this point). And if you *don't*
+want some of these advantages (probably distributed hypermedia) you can go back to chapter 2, start the process over,
+and end up with a differently optimized architecture.
+
+I don't have any direct experience with GraphQL, though I'm about to get some at my current job, so take this with a
+grain of salt:
+
+On a technical level, GraphQL is solving a problem that's very common in API design: performing a database query across
+a network connection without sending a bunch of unneeded data over the wire. Looking at the docs I see it also has "
+Mutations" which seem very SOAP-ish. I guess I'd say GraphQL looks like a modern version of SOAP, optimized for the
+common case of querying a database.
+
+Since GraphQL is independently deployable, supports multiple server implementations and defines no domain-specific
+semantics, an interoperable domain-specific API could be built on top of it. Rather than exporting your data model to
+GraphQL and clashing with a dozen similar data models from the same industry, you could get together with your peers and
+agree upon a common set of semantics and mutations for your problem space. Then you'd have interoperability. It's not
+much different from what we did with OPDS in the library world, defining what concepts like "bookshelf" and "borrow"
+mean.
+
+Would it be RESTful? Nope\! But again I'll come back to SIP, the integration protocol that public libraries use to keep
+track of loans. SIP is a level zero protocol\! It doesn't use any of the Web technologies at all\! But it provides
+architectural properties that libraries value and vendor-centric solutions can't offer–mainly interoperability–so it
+sticks around despite the presence of "RESTful" solutions.