Leonard Richardson 是一位资深程序员和作者，他创建了后来被称为 Richardson Maturity Model (https://en.wikipedia.org/wiki/Richardson_Maturity_Model) 的系统， 该系统用于根据 Web API 对 REST 的遵守程度对其进行分类。在此，Web API 指 data APIs，即旨在 由自动化系统或代码消费的数据，而不是直接由 Web 客户端消费。
RMM 由四个级别组成：
Web API 随着采用这些技术和约定而变得更加成熟。
Leonard 同意与我谈论 RMM 以及他构建 Web 软件的经历。
问题：您能介绍一下您的背景以及您如何进入 Web 编程领域吗？您是否/曾经认为自己是超媒体爱好者？
当我在 1990 年代中期上高中时，我通过 BBS 获取了非常基本的互联网访问权限。那时有各种令人惊叹的、晦涩的协议需要学习才能导航：FTP、Gopher、Archie、NNTP 等。然后就在我上大学时，World Wide Web 突然取代了所有这些特定领域的协议。几年之内，我们就开始使用 Web 技术——URI、HTTP 和 HTML——来处理一切。
我作为开发者的成长经历发生在这些三种核心技术的惊人力量的背景下。一切都建立在 Web 之上，而且它基本上有效，并且比旧方式简单得多。
所以是的，我是一位超媒体爱好者，但花了很长时间我才理解 Web 的“超媒体”部分带来的独特优势。而且这种理解来自于认识到这些优势在商业角度何时无关紧要或不受欢迎。
问题：您能简要介绍一下早期 Web API 的历史吗？RMM 的起源故事是什么？
我们现在称之为“Web API”的东西起初是对 SOAP 的反动，SOAP 是一种来自企业防火墙允许 HTTP 连接（必要以完成工作）但阻止大多数其他流量（游戏？）的时代的技术。SOAP 允许您将过程调用序列化为 XML 并通过 HTTP 连接调用它，从而穿透防火墙。它是一个极其重量级的解决方案，使用了制作良好轻量级解决方案所需的确切相同工具——XML 和 HTTP。
现在作为一个老家伙，我回顾 SOAP 可以看到上一代老家伙试图让 1990 年代的客户端-服务器范式在互联网上运行。SOAP 一度拥有大量的心智份额，但公开部署的 SOAP 服务很少。当您在公共互联网上部署服务时，人们期望能够从各种编程语言和编程环境中连接到它。SOAP 不适合这样做，因为它太重，并且需要大量工具来补偿其重量。
相反，开发者从核心 Web 技术中挑选和选择他们的设计。由于互联网泡沫，那些技术被实践开发者理解，并且由每种主要编程语言很好地支持。
RMM（现在这样称呼）最初是我在 2008 年的一次演讲 中提出的启发式方法。演讲的第一部分 回顾了我之前提到的早期历史， 而 第二部分 谈论了我第一次尝试向雇主推销基于超媒体的 API 设计经历。
我为我的 REST 书籍分析了大约一百种 Web API 设计，并看到了围绕核心 Web 技术的非常强烈的分组。您会看到许多“理解”URL 但“不理解”HTTP 的 API。但您永远不会看到相反的情况，即一个利用 HTTP 特性但不知道如何处理 URL 的 API。如果我有一个洞见，那就是 URL 是最基本的 Web 技术。HTTP 是一组高效处理 URL 的规则，而 HTML（又称超媒体）是一组驱动 HTTP 客户端的指令。
问题：在“How Did REST come to mean the opposite of REST？”中，我断言 REST 这个术语的含义几乎完全颠倒了。特别是，我声称大多数 API 停留在 RMM 的“Level 2”级别。您同意这些说法吗？
如今每个人都理解 URI，而且理解 HTTP 对于性能原因至少是必不可少的。这会带您到级别 2，是的，我们一直停留在那里。这就是我在 2007 年的这次访谈 中所指出的内容，那是在我进行著名演讲的前一年：
我脑海中的一个大问题是，是否有意识地以 REST 为基础设计的架构将“赢得”那些简单但只是间歇性地 RESTful 的架构。
您不会因为达到级别 3 而获得 Roy Fielding 签署的证书。学习并应用超媒体教训的奖励是 interoperability。您的用户获得以您未预料到的方式使用您的系统能力，并且他们可以将您的系统与其他系统结合。
在像 Web 这样的情况下，互操作性是必不可少的，那里有数百万服务器和客户端部署，以及十几个主要服务器实现。（现在只有两个主要客户端实现，但那是一个悲伤的故事。）
很长一段时间我认为人们只是不理解这一点，如果我反复强调超媒体的技术优势，他们就会转变。但我们已经停留在级别 2 超过 Web 寿命的一半。这让我清楚，大多数情况不像 Web 那样，超媒体的优势与大多数商业模式无关。
问题：级别 3 风格的超媒体控制在 Web API 中从未真正流行起来。您认为原因是什么？
我不是对一切都这样做，但我要把这个归咎于资本主义。
几乎所有实际部署的 Web API 都完全由一家公司控制。它们有一个由该公司编写的服务器实现和一个由该公司管理的服务器部署。如果 API 有任何官方客户端实现，那些也由拥有 API 的公司控制。我们说“[公司] API”这一事实就是互操作性的反面。
用户喜欢互操作性，但供应商更喜欢锁定。我们从他们的行为中看到了这一点。Netflix 很高兴为他们的节目数据提供超媒体 API……直到他们的流媒体业务变得足够大。一旦他们成为主导玩家并能够 dictation 集成条款，Netflix 就关闭了他们的 API。Twitter 曾经如果您的客户端太受欢迎就会切断您的 API 访问；然后他们完全禁止第三方客户端。
有很多 API 将互操作性视为一个强项，其中许多都围绕超媒体，但几乎所有它们都存在于商业竞争之外的空间。在 2008 年我进行“成熟度启发式”演讲时，我在 Canonical 从事软件开发工具工作，Canonical 是一家营利公司，但深度参与开源开发。我们希望许多工具和编程环境能够与我们的 API 对话，但 API 是我们过程的相对较小部分，我们没有足够的开发者来管理一堆官方客户端。基于超媒体的方法给了我们一定的灵活性，可以在不破坏所有客户端的情况下更改我们的 API。
在那之后，我花了八年时间在美国公共图书馆领域从事电子书交付工作，该领域在 IT 管理方面极其碎片化。在一个非营利环境中，有大量独立的服务器部署，超媒体（以 OPDS 协议的形式）是一个非常容易推销的东西。我做过一个关于那个的演讲。
要获得超媒体的好处，您必须与同一领域中的其他人合作，考虑整个问题空间，并想出一个适合每个人的设计。当奖励是“无供应商锁定”时，谁会经历所有这些工作？那些不与同行竞争的人：科学家、图书馆员和开源开发者。
您可能会感到惊讶或不惊讶地得知，图书馆世界被一种名为 SIP 的古董协议主导。（ 不是 VoIP 协议，是一个不同的 SIP。）SIP 是自助结账机用来记录您借书事实的协议。SIP 首次出现在 1993 年，其设计明显非 RESTful，而且在许多方面它简直是 bad。 每个图书馆供应商都想出了他们自己的级别 2 “REST” 协议来做 SIP 所做的事情。但没有一个成功取代 SIP，因为那个可怕的 1993 年旧设计提供了一些供应商无法提供的东西：不同 供应商组件之间的互操作性。我也做过一个关于那个的演讲。
问题：您认为从 XML 到 JSON 作为格式的转变是否对 Web API 的演变产生了任何影响？
绝对是。从 XML 到 JSON 的转变将文档中心的设计（更适合一端有人的通信）替换为数据中心的设计（更适合机器到机器通信）。代价是完全忘记了超媒体。
我认为 Martin 的图表中模糊多于揭示的一件事是：他称级别 0 为“Swamp of POX”。这让它看起来像是（Plain Old）XML 的问题。Martin 实际上在那里谈论的是 SOAP。SOAP 服务的一个大问题是它不使用 URL（尽管它们确实有太多 XML），而是将所有请求信息放入 XML 包中，并通过单个服务端点隧道传输。这使得 SOAP 对设计用于管理、监控和检查 HTTP 流量的工具不透明。这是故意设计的，因为 SOAP 的目的是让您在 IT 部门锁定除了端口 80 以外的一切时进行 RPC 调用。
总之，XML 很棒！它太冗长而无法成为高效的数据表示格式，但 XML 有命名空间，通过命名空间它有超媒体控制（通过 XLink、XForms、XHTML、Atom 等）。JSON 没有超媒体控制，而且因为它也没有命名空间，您无法事后添加它们。
人们开始采用 JSON 因为他们厌倦了 XML 处理并对 AJAX（对于那些不在场的人：由 Javascript 驱动的浏览器内 HTTP 客户端）感到兴奋。但那个初始决定开始限制后续的决定。
到 2011 年，所有新的 Web API 都使用没有超媒体控制的表示格式。如果您想的话，您无法进行基于超媒体的设计。我们的技术语言已经失去了这些词。首先您必须定义一个具有超媒体的基于 JSON 的媒体类型（如 Siren），或命名空间（如 JSON-LD）。
问题：您对 GraphQL 和其他非 RESTful API 技术的看法是什么？
关于非 RESTful API 技术一般来说，我建议大家从 Roy Fielding 论文的 第 5 章 中休息一下， 并看看第 2 和 4 章。
第 5 章是 Fielding 谈论 Web 设计的地方，但第 2 章分解了网络应用架构中您可能想要的所有可能的好处，其中只有一些适用于 Web。第 4 章解释了设计 Web 时做出的权衡，以牺牲其他好处换取一些好处的。
第 4 章列出了 Web 的五个主要优势：低进入门槛、可扩展性、分布式超媒体、无政府可扩展性和独立部署。REST 是获得这些优势的非常有效的方法，但这些优势本身才是您真正想要的。如果您可以在没有 Web 技术的情况下获得它们，那么您失去的只是这些技术带来的积累的专业知识（尽管这在此时并非无足轻重）。而且如果您 不 想要这些优势中的一些（可能是分布式超媒体），您可以回到第 2 章，从头开始过程，并最终得到一个不同优化的架构。
我没有直接使用 GraphQL 的经验，尽管我在当前工作中即将获得一些，所以请盐巴对待这个：
在技术层面，GraphQL 正在解决 API 设计中非常常见的问题：在网络连接上执行数据库查询，而不发送大量不必要的数据通过线路。从文档中我看到它还有“Mutations”，这看起来非常像 SOAP。我想说 GraphQL 看起来像是 SOAP 的现代版本，针对查询数据库的常见情况进行了优化。
由于 GraphQL 是独立可部署的、支持多个服务器实现并且不定义特定领域的语义，因此可以在其之上构建互操作的特定领域 API。与其将您的数据模型导出到 GraphQL 并与同一行业中十几个类似数据模型冲突，不如与您的同行聚在一起，同意您的问题空间的通用语义和突变集。然后您就会有互操作性。这与我们在图书馆世界中对 OPDS 所做的没什么不同，定义了像“bookshelf”和“borrow”这样的概念的含义。
它会是 RESTful 吗？不！但我再次会回到 SIP，这是公共图书馆用来跟踪贷款的集成协议。SIP 是一个零级协议！它根本不使用任何 Web 技术！但它提供了图书馆重视的架构属性，而供应商中心解决方案无法提供——主要是互操作性——因此尽管有“RESTful”解决方案的存在，它仍然坚持下来。