文章摘要
大多数所谓的RESTful API并未真正遵循REST架构风格。REST最初由Roy Fielding在其博士论文中提出，强调可扩展性、简单性和适应性，而非局限于HTTP动词或CRUD操作。当前的API实现往往偏离了REST的核心原则，导致其未能充分发挥REST的潜力。
文章总结
文章主要内容总结
标题: 大多数RESTful API并不是真正的RESTful
发布时间: 2025年7月7日
来源: Florian Kraemer的博客
1. REST的起源与定义
REST（Representational State Transfer）是由Roy Thomas Fielding在其博士论文《Architectural Styles and the Design of Network-based Software Architectures》中提出的架构风格，旨在设计可扩展、高性能且易于维护的网络系统，特别是Web服务。REST的核心原则包括无状态接口、基于资源的交互以及超媒体驱动的应用状态转换。
2. REST的误解与简化
Fielding批评了当前许多所谓的“RESTful”API，指出它们并未真正实现REST的关键约束，尤其是超媒体作为应用状态引擎（HATEOAS）的缺失。HATEOAS要求客户端通过服务器响应中的超媒体链接动态发现操作，而不是依赖外部文档或硬编码的URI结构。
3. HATEOAS的重要性
HATEOAS的核心在于解耦客户端与服务器的URI结构，使系统更具可演化性。通过嵌入超媒体链接，客户端无需预先知道URI结构，而是通过服务器提供的链接动态导航。例如：
json
{
"orderId": 123,
"_links": {
"self": { "href": "/orders/123" },
"cancel": { "href": "/orders/123/cancel", "method": "POST" }
}
}
4. 资源的定义
在REST中，资源可以是任何可以通过URI标识的事物，包括文档、服务、抽象概念等。资源并不等同于持久化实体，而是对一组实体的概念映射。Fielding强调，URI的语义由资源的创建者定义，客户端和服务器无需理解URI的含义。
5. RESTful API的六条规则
Fielding提出了六条规则，用于判断一个API是否真正符合REST风格： 1. 不依赖单一通信协议。 2. 不改变现有协议，仅填补标准协议的空白。 3. 专注于媒体类型和超媒体，而非URI结构。 4. 不定义固定的资源名称或层次结构。 5. 避免资源类型对客户端的影响。 6. 客户端仅需初始URI和标准媒体类型，后续操作由服务器提供的链接驱动。
6. 为什么大多数API不是真正的RESTful
大多数API采用了一种简化的RPC风格，主要原因包括： - 工具和开发者体验：OpenAPI等规范提供了自动代码生成、交互式文档等功能，使得静态合约成为“足够好”的选择。 - 认知负担：构建真正的超媒体驱动客户端被认为复杂且耗时，开发者更倾向于硬编码URI模板。 - 紧密耦合的客户端与服务器：在前后端由同一团队开发的场景中，HATEOAS的客户端解耦优势并不明显。
7. 结论
Fielding强调，真正的RESTful API应以超媒体为核心交互机制，而不是仅仅将HTTP作为传输层。REST的核心是协议无关性，客户端应通过嵌入在表示中的链接和标准化关系动态发现和导航资源。REST的目标是构建松散耦合、可演化的分布式系统，使其行为与Web本身一致。
建议：在设计和实现API时，应根据实际需求和消费者的情况做出务实的选择。如果目标是客户端解耦和动态交互，HATEOAS是一个强大的设计选择；如果API仅服务于单一前端，简化的RPC风格可能更为实用。
评论总结
以下是评论内容的总结，涵盖了主要观点和论据：
1. 对REST的实用性与复杂性的讨论
- 支持简化API设计：许多评论者认为，RESTful API的设计过于复杂，实际开发中更倾向于使用简化的RPC风格API。例如，
TekMol提到，简单的URL参数API更容易实现和测试，而pbreit指出，HATEOAS增加了响应负载，但实际使用中很少被用到。- 引用：
TekMol：“Because that is the easiest to implement, the easiest to write, the easiest to manually test and tinker with.” - 引用：
pbreit：“Our API includes HATEOAS links and I have never, not once, witnessed their actual use.”
- 引用：
- REST的学术性与实际脱节：
leourbina和thom等评论者认为，REST的学术定义过于理想化，实际开发中难以实现，且并未带来显著的好处。- 引用：
leourbina：“The article comes across more as academic pontification on ‘what not to do’ instead of actionable advice.” - 引用：
thom：“I struggle to believe that any API in history has been improved by the developer more faithfully following REST’s strictures.”
- 引用：
2. 对HATEOAS的质疑
- HATEOAS的实用性：
sublinear和dwaltrip等评论者认为，HATEOAS在实际应用中并不实用，且增加了客户端的复杂性。- 引用：
sublinear：“I just don’t see what the big deal is if we have more robust ways of serving the docs somewhere else outside of the JSON response.” - 引用：
dwaltrip：“What kind of magical client can make use of an auto-discoverable API?”
- 引用：
- HATEOAS的复杂性：
imtringued指出，HATEOAS要求客户端能够处理任意变化的API结构，这在实际开发中几乎不可能实现。- 引用：
imtringued：“Your client needs to handle any theoretical API that could come from the server.”
- 引用：
3. REST与RPC、GraphQL的对比
- RPC风格的实用性：
bravesoul2和Traubenfuchs等评论者认为，RPC风格的API更简单、更实用，适合大多数开发场景。- 引用：
bravesoul2：“RPC with status codes = Grin and point. I like to get stuff done.” - 引用：
Traubenfuchs：“Adding actions to it! POST to api/user:signup, boom!”
- 引用：
- GraphQL的RESTful特性：
theknarf认为，GraphQL在某些方面比REST更符合Fielding的原始定义。- 引用：
theknarf：“Ironically it feels like GraphQL is more RESTful than most REST api’s.”
- 引用：
4. REST的适用场景
- REST的特定用例：
salmonellaeater指出，REST适用于用户通过浏览器等代理与API交互的场景，但大多数Web API并不需要这种设计。- 引用：
salmonellaeater：“REST API design is for use-cases where the users should have control over how they interact with the resources provided by the API.”
- 引用：
- REST与前端开发的脱节：
Scarblac认为，RESTful API在实现前端UI时并不实用，因为前端开发者需要更多的控制权。- 引用：
Scarblac：“RESTful APIs as described in the article aren’t useful for the most common use case of Web APIs, implementing frontend UIs.”
- 引用：
5. 对REST术语的语义扩散
- REST术语的滥用：
cjpearson和alkonaut等评论者指出，REST术语已经被广泛滥用，实际开发中的“REST API”与Fielding的原始定义相去甚远。- 引用：
cjpearson：“When I see ‘REST API’ I can safely assume the following: The API returns JSON, CRUD actions are mapped to POST/GET/PUT/DELETE.” - 引用：
alkonaut：“The sad truth is that it’s the less widely used concept that has to shift terminology.”
- 引用：
6. REST的未来与替代方案
- REST的替代方案：
dingi和liendolucas等评论者认为，REST的复杂性使得许多开发者选择更简单的替代方案，如HTML渲染或GraphQL。- 引用：
dingi：“Building truly RESTful APIs has been easy for ages, just render HTML on the server and send it to the browser.” - 引用：
liendolucas：“LMAO all companies asking for extensive REST API design/implementation experience in their job requirements.”
- 引用：
总结：
评论中普遍认为，RESTful API的设计过于复杂且在实际开发中并不实用，许多开发者更倾向于使用简化的RPC风格或GraphQL。HATEOAS被认为增加了不必要的复杂性，且在实际应用中很少被使用。REST术语的语义扩散也导致其原始定义被广泛滥用。尽管REST在某些特定场景下有其优势，但在大多数现代Web开发中，更简单的API设计更受青睐。