什么是REST API？约束、资源和设计
无抓取抓取API提供特定任务的HTTP接口，返回结构化的公共网页数据以供应用程序工作流程使用。
简而言之
- REST是一种架构风格。 REST API对网络交互施加约束，而不是规定一个端点模板或数据格式。
- 资源通过表示被识别和交换。 客户端在不直接接收服务器内部对象的情况下，对资源状态进行操作。
- HTTP与REST非常契合，但并不保证它。 使用URLs、JSON和常用方法仍然可以产生RPC风格的接口。
- 无状态请求携带处理所需的上下文。 服务器端应用程序数据仍然存在；该约束涉及谈话客户端会话状态。
- 可缓存性和统一接口支持扩展性。 它们减少耦合，允许中介理解交互。
REST API定义
REST API是根据表现层状态转移架构风格设计的应用程序编程接口。REST描述了分布式超媒体系统中组件的约束。它不要求使用JSON、单一URL模式或特定编程语言。Web API通常通过HTTP应用REST思想，因为HTTP已经提供了标识符、方法、表示、元数据、缓存和中介。
核心抽象是资源：一种可以随时间识别的概念事物。服务器发送资源状态的表示，例如JSON或XML文档，而不是转移其内部数据库对象。客户端解释该表示并遵循接口语义。 原始REST架构描述 解释了约束如何支持可见性、可扩展性和独立演进。
实践中的REST约束
“什么是REST API”背后的机制跨越不止一个软件或网络边界。命名每个阶段使性能、正确性和安全性检讨变得具体。
客户端-服务器和无状态交互
客户端关注与服务器数据和行为分离。每个请求包含理解请求所需的信息，而不是依赖于早先请求中的隐含对话状态。身份验证状态或存储资源可能存在；该约束并不要求没有记忆的服务器。
缓存和分层系统
响应定义了它们是否可以被重用。网关、代理和其他中介可以在客户端和源之间存在，而不改变客户端看到的接口。正确的元数据让缓存减少重复工作，同时保持表示语义。
统一接口和按需可选代码
组件通过一套一致的概念进行交互：被识别的资源、表示、自描述消息和超媒体控件。按需代码是可选的约束，允许可执行代码在系统选择使用时扩展客户端行为。
REST概念及其HTTP表达
团队通常在对标签达成一致的同时假设不同的行为。这些行将“什么是REST API”转变为明确的合同和操作问题。
| 概念 | 含义 | 实用信号 |
|---|---|---|
| 资源标识符 | 标识概念资源。 | 如集合或记录地址的HTTP URI。 |
| 表示 | 携带资源状态的当前视图。 | JSON、XML、HTML、文档或其他协商的媒体类型。 |
| 方法语义 | 表达交互的意图。 | 安全读取、创建、替换、修改或移除，如文档所述。 |
| 状态和元数据 | 描述结果和表示。 | 状态码、内容类型、验证器、缓存控制和链接。 |
| 超媒体控制 | 广告可用的状态转换。 | 链接或表单，其含义由媒体类型和关系定义。 |
REST API适合的地方
采用或优化REST API的最强理由是与工作流程的可测量契合。这些场景描述了这种契合，而不将该术语视为普遍默认值。
面向资源的服务
集合和记录自然映射到稳定的标识符和标准交互语义。
公共平台API
HTTP 工具、缓存、网关以及广泛的语言支持使得接口在各个组织中更易于接触。
独立客户
一个稳定的统一接口让移动、网页、命令行和合作伙伴客户端可以在不同的发布计划上独立发展。
可缓存读取
使用正确的验证器和新鲜元数据的表示可以减少源工作和网络传输。
如何设计或评估REST API
从领域资源及其标识符开始，然后定义表示和转换。避免将每个业务动作都转化为任意动词形状的 URL。一些操作并不能简单地映射到基本资源变更上；它们仍然可以建模为资源、作业或命令，但清晰性比外观纯粹性更重要。
使用 HTTP 语义一致。 当前的HTTP语义标准 定义方法属性、状态代码、字段和表示概念。安全方法不应被记录为执行不安全的业务变更。缓存元数据、条件请求和内容协商应反映真实行为，而非复制的头信息。
将设计错误和分页视为合同的第一类部分。客户需要稳定的错误标识符、可读的详细信息、字段级验证上下文以及关联事件的方法。大型集合需要确定性的排序和在数据变化时保持正确的继续规则。授权应针对每个资源和操作进行评估，而不仅仅是从拥有标识符推断。
常见的 REST API 设计错误
- 将任何基于HTTP的JSON接口称为REST。 传输和媒体类型并不能证明架构约束存在。
- 混淆无状态性与没有存储数据。 REST 服务器存储资源；它们避免了在后续请求中解释所需的隐含对话上下文。
- 针对每个结果返回一个状态。 当验证、授权、缺失、冲突和服务器故障看起来相同的时候，客户会失去有用的语义。
- 使用没有模型的缓存头。 不正确的新鲜度或验证者可能会传递过时的数据或阻止安全重用。
- 在版本更改期间破坏标识符。 稳定的资源身份和明确的兼容性政策比装饰性的 URL 约定更为重要。
数据收集系统中的 REST API
一个REST风格的数据源通常会暴露分页集合和项资源。收集器应遵循记录的续订链接或游标，记录响应元数据，验证表示，并保留源标识符。当API提供续订控制时，不应随意创造未记录的分页数学。
条件请求可以使重复的收集在服务发布验证器时更有效。客户端询问表示是否发生了变化，仅在需要时处理主体。这可以减少传输和源工作，但前提是源合同记录了语义，而收集器将验证器与相应的资源存储在一起。
当所需的公共数据仅通过渲染页面提供时，浏览器或抓取接口可以提供获取层。将该步骤与暴露给下游消费者的标准化内部REST服务分开。分离允许源特定的渲染和解析在不强迫每个消费者更改的情况下发生变化。
什么是REST API评审检查清单
使用这些检查将什么是REST API的定义转化为开发人员、操作人员或审阅者可以复制的实施证据。
- 翻译以下文本从英语到中文。 规则： 1. 仅输出翻译后的文本 — 不加任何说明，不添加额外的包装代码框。 2. 保留Markdown/HTML结构（标题、列表、链接、表格）完全不变。 3. 保持任何占位符标记如 @@CODEBLOCK_0@@ 或 @@INLINECODE_0@@ 完全不变；绝不要翻译、重新排序、合并或重新格式化它们。 4. 不要添加或删除 ``` 代码框，也不要将普通文本包裹在代码块中。 重申边界。 什么是REST API，识别调用者、提供者、路径以及标记完整结果的确切事件。
- 验证中心主张。 确认此声明及其文档：REST是一种架构风格。REST API对网络交互施加约束，而不是规定一个端点模板或数据格式。
- 追踪机制。 观察客户端-服务器和无状态交互，缓存和分层系统，统一接口和按需可选代码，并记录每个阶段由哪个组件拥有。
- 检查最近的区别。 文档说明为什么资源标识符意味着“命名概念资源。”在此系统中。
- 请测试一个代表性的用例。 使用具有真实数据、位置、数量和权限边界的资源导向服务。
- 防范已知错误。 审查“将任何JSON-over-HTTP接口称为REST。”并添加一个接受检查来捕获它。
- 绑定工作量。 为什么 REST API 设置合适的主题限制，包括有效载荷、并发、执行时间和适用的存储输出。
- 记录决策。 解释为什么 REST API 适合这个边界，并列出稍后可以证明不同方法的证据。
结论
REST API 应该描述设计中的一个可测试部分，而不是作为周边行为的宽松标签。审查应保留这一中心决策：REST 是一种架构风格。 REST API 对网络交互施加约束，而不是规定一个端点模板或数据格式。它还应防止将任何 json-over-http 接口称为 REST，并保持 REST API 的访问在接口或网络的文档政策内。
准备好构建您的网络数据工作流程了吗？
将一个测量过的 REST API 获取或集成步骤连接到上述描述的验证和存储实践。
今天注册并获得 $5 的免费信用 — 无需信用卡.
领取您的 $5 信用 →常见问题解答
REST 代表什么？
REST 代表表现状态转移。这个名称指的是通过一种受限的、面向网络的架构风格来转移资源状态的表现。
REST API 一定是 HTTP 和 JSON 吗？
不。REST 是一种架构风格，并不强制使用 HTTP 或 JSON。HTTP 与 REST 概念相得益彰，而 JSON 是一种常见的表现形式，因此这种组合广泛存在。
什么使 API 成为 RESTful？
RESTful API 遵循 REST 约束：客户端-服务器分离、无状态交互、可缓存性、统一接口、分层系统，和可选的按需代码。现实世界的接口可能在不同程度上应用这些约束。
REST 和 RESTful 之间有什么区别？
REST 是一个架构风格的名称，而 RESTful 描述的是根据该风格设计的系统。在普通的 API 讨论中，REST API 和 RESTful API 经常可以互换使用。