Leonard Richardson是资深程序员、作家，他创建的模型后来被称为理查森成熟度模型（RMM）（https://en.wikipedia.org/wiki/Richardson_Maturity_Model），用于根据Web API对REST的遵循程度分类。此处Web API指数据API（供自动化系统或代码使用），而非直接由Web客户端使用。
RMM包含四个层级：
采用这些技术和约定后，Web API成熟度逐步提升。
Leonard同意与我讨论RMM及他的Web软件开发经验。
问：请介绍您的背景及如何进入Web编程？您是否自视为超媒体爱好者？
1990年代中期高中时，我通过BBS获得基础网络访问。那时需掌握FTP/Gopher/Archie/NNTP等神秘协议才能上网。刚进大学时，万维网突然抹平了所有领域专用协议。几年内，我们开始用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技术存在强分组。常见API"理解"URL但不"理解"HTTP。但反之绝不存在——没有利用HTTP特性却不懂URL的API。我的核心洞察是：URL是最基础的Web技术。HTTP是高效处理URL的规则集，HTML（即超媒体）是驱动HTTP客户端的指令集。
问：在《REST如何走向REST的反面》中，我断言REST一词含义几乎被颠倒。尤其指出多数API停在RMM"层级2"。您认同吗？
如今人人都懂URI，理解HTTP对性能等至关重要。这达到层级2，是的，我们停滞于此。这正是我2007年访谈（著名演讲前一年）的观点：
我心中的大问题是：有意识采用REST设计的架构会战胜简单但间歇遵循REST的架构吗？
达到层级3不会获得Roy Fielding签署的证书。学习应用超媒体的回报是互操作性。用户能以你未预料的方式使用系统，并能将你的系统与其他系统结合。
在Web（数百万服务器/客户端部署、十余种主流服务实现）等场景中，互操作性至关重要。（现仅存两种主流客户端实现，但这是另一悲剧。）
长久以来我以为人们不懂这点，若我强调超媒体技术优势他们会醒悟。但我们在层级2停滞了超半数Web生命周期。现在清楚多数场景不像Web，超媒体优势与多数商业模式无关。
问：层级3式超媒体控件未在Web API中普及，您认为原因何在？
我不常归因于此，但这次要怪资本主义。
几乎所有实际部署的Web API完全由单公司控制。该公司编写一种服务实现并管理部署。若API有官方客户端实现，也由该公司控制。我们说"某公司API"本身就与互操作性背道而驰。
用户喜欢互操作性，供应商偏爱锁定。Netflix曾为其节目数据提供超媒体API...直到流媒体业务壮大。一旦成为主导者并能规定集成条款，Netflix便关闭API。Twitter曾因客户端太流行而切断API访问，后彻底禁止第三方客户端。
许多重视互操作性的API采用超媒体导向，但几乎都存在于商业竞争之外。2008年我发表"成熟度启发"演讲时，在Canonical（营利但深度参与开源）从事开发工具。我们希望多种工具/编程环境能与API交互，但API是流程中较小部分且开发者不足。超媒体方案赋予我们变更API而不破坏客户端的灵活性。
之后八年我在美国公共图书馆领域从事电子书交付（IT管理高度碎片化）。非营利环境含大量独立服务部署，超媒体（以OPDS协议形式）成为轻松推销的方案。我为此做过演讲。
要获得超媒体优势，需与同领域伙伴协作，通盘考虑问题并提出普适设计。当回报是"无供应商锁定"时，谁愿投入这些工作？非竞争同行：科学家、图书馆员、开源开发者。
图书馆界被称SIP（非VoIP协议）的古老协议主导。自助借书机用SIP记录借书。SIP出现于1993年，设计明显非RESTful且多层面堪称糟糕。每家图书馆供应商都推出层级2"REST"协议替代SIP，但无一成功——因为那个糟糕的1993设计提供了供应商无法给予的：不同供应商组件间的互操作性。我也为此演讲过。
问：您认为从XML转向JSON是否影响了Web API演变？
绝对有。从XML转向JSON将以文档为中心（更适合人机通信）的设计转为以数据为中心（更适合机机通信）的设计。代价是完全遗忘了超媒体。
Martin图表中我认为模糊多于揭示的是：他称层级0为"POX沼泽"。实际指SOAP。SOAP服务的核心问题不是XML（尽管XML过多），而是不使用URL。SOAP客户端将所有请求信息打包XML并通过单一服务端点传输，使其对管理/监控/检查HTTP流量的工具不透明——这恰是设计目标：在IT部门仅开放80端口时实现RPC调用。
XML很棒！作为高效数据表示格式太冗长，但XML通过命名空间拥有超媒体控件（XLink/XForms/XHTML/Atom等）。JSON无超媒体控件，且无命名空间导致无法后续添加。
人们因厌倦XML处理且兴奋于AJAX（浏览器端HTTP客户端）而采用JSON。但这个初始决策制约了后续选择。
到2011年，所有新Web API都使用无超媒体控件的表示格式。即使想做超媒体设计也无能为力。技术语言已丧失词汇。需先定义含超媒体的JSON媒体类型（如Siren）或命名空间（如JSON-LD）。
问：您对GraphQL等非RESTful API技术的看法？
关于非RESTful API技术，建议人们暂离Roy Fielding论文第5章，看看第2章和第4章。
第5章谈Web设计，但第2章分解了网络应用架构所有可能优势（仅部分适用于Web）。第4章解释设计Web时的权衡，以牺牲某些优势换取其他好处。
第4章列出Web五大优势：低门槛、可扩展性、分布式超媒体、无政府可扩展性、独立部署。REST是获得这些优势的有效方式，但优势本身才是核心。若脱离Web技术也能获得，你损失的只是这些技术积累的专业知识（尽管目前并非一文不值）。若不需要某些优势（可能是分布式超媒体），可回溯第2章重新设计不同优化的架构。
我无GraphQL直接经验（但即将在工作中接触），以下观点请斟酌：
技术上GraphQL解决API设计常见问题：跨网络执行数据库查询而不过度传输数据。文档中我还看到"变更"（Mutation）——非常SOAP风格。可以说GraphQL像现代版SOAP，针对数据库查询优化。
由于GraphQL可独立部署、支持多服务实现且未定义领域特定语义，可在其上构建互操作的领域特定API。与其将数据模型导出到GraphQL并与同行业数十相似模型冲突，不如与同行商定问题空间的通用语义和变更。这样便获得互操作性——与我们在图书馆界用OPDS所做无本质区别。
这会RESTful吗？不！但再以SIP为例（公共图书馆用于跟踪借阅的集成协议）。SIP是层级0协议！完全不使用Web技术！但它提供了图书馆重视且供应商中心方案无法提供的架构属性——主要是互操作性——所以尽管存在"RESTful"方案，它仍存续至今。