Rest API 的架构限制

这个著名的缩写代表“表征状态转移”（Representational State Transfer），是一种软件架构风格。其最常见的用途是通过标准化、通用的方法来简化 Web 服务的使用。

这些 Web 服务以文本形式提供 Web 资源，并允许通过无状态协议进行读取和处理。客户端可执行的操作是预定义且众所周知的，通常基于 HTTP 协议。

RESTful API 和软件并非基于某种技术或编程上的突破。它们甚至并不算新，最早可追溯至 2000 年。REST 的核心理念是向 API 施加特定规则，从而获得更高的性能、可扩展性、简洁性、可修改性、可视性、可移植性和可靠性。

这些优势固然显著，但您可能会问：REST API 是如何实现这些优势的？答案很简单，只需遵循六项约束。事实上，这些规则正是 RESTful 架构风格最鲜明的特征。

API 的职责是连接两套软件，同时不限制它们各自的功能。这一目标是 REST 的核心约束之一：客户端（发起请求）与服务器（返回响应）保持分离且独立。

若设计得当，客户端和服务器便能朝着不同的方向进行更新和演进，而不会影响数据交换的质量。这一点在服务器需要服务大量不同客户端的各种场景中尤为重要。试想天气 API——它们必须从单一数据库向成千上万的不同客户端（各类移动设备便是很好的例子）发送数据。

要成为无状态的 API，它必须独立处理每次调用。每次 API 调用都必须包含完成所需操作所需的数据和指令。

非无状态 API 的一个例子是：在会话期间，仅首次调用需要包含 API 密钥，该密钥随后会被存储在服务器端。后续的 API 调用依赖于首次调用，因为它提供了客户端的凭据。

而在相同情况下，无状态 API 会确保每次调用都包含 API 密钥，且服务器每次都会要求验证访问凭证。

无状态 API 的优势在于，单次调用出现错误或失败不会影响后续调用。

尽管客户端和服务器会以不同方式发生变化，但 API 仍需能够促进通信。为此，REST API 规定了一个统一的接口，可轻松适配所有相关软件。

在大多数情况下，该接口基于 HTTP 协议。除了规定客户端与服务器之间的交互规则外，它还具有在互联网上广为人知且被广泛使用的优势。由于 JSON 文件具有多功能性，数据通常通过它们进行存储和交换。

为了确保 API 易于理解且具备可扩展性，RESTful 架构要求设计采用分层结构，各层协同运作。

在明确的层级结构下，执行一条命令意味着每一层都履行其职能，然后将数据传递给下一层。相连的层之间相互通信，但不会与程序的每个组件都进行交互。这样，API 的整体安全性也得到了提升。

若 API 的范围发生变化，可在不影响接口其他组件的前提下，对各层进行添加、修改或移除。

无状态 API 的请求通常会产生较大的开销。在某些情况下，这是不可避免的，但对于需要相同数据的重复请求，缓存这些信息将产生显著效果。

其原理很简单：客户端可选择将特定数据在本地存储预定时间。当客户端请求该数据时，服务器不再重复发送，而是直接使用已存储的版本。

结果显而易见：客户端无需在短时间内发送多次复杂或耗费资源的请求，只需执行一次即可。

与此前讨论的其他限制不同，最后一项是可选的。将“按需代码”设为可选的原因很简单：它可能带来巨大的安全风险。

其核心理念是允许通过 API 发送代码或小程序供应用程序使用。不难想象，来自可疑来源的未知代码可能造成破坏，因此该约束最好仅用于内部 API——在这些场景中，您无需过多担心黑客或恶意用户的威胁。另一个缺点是，代码必须采用与应用程序匹配的编程语言，而现实中往往并非如此。

其优势在于，“按需代码”能帮助客户端在运行时即时实现自定义功能，从而减少API或服务器端的工作量。本质上，这使得整个系统具备更强的可扩展性和敏捷性。

在网络主导的时代，RESTful 设计的重点在于效率和可扩展性。正如您所想象的那样，这使得这种架构广受欢迎，未来几年我们很可能会看到它变得更加普及。

许多开发者和安全专家的主要担忧在于，如果Web API在设计时不够谨慎，它们将面临多大的被利用风险。当然，黑客一直是、也将会继续是API乃至整个软件领域面临的问题。但这并不意味着我们会停止使用它们。相反，安全专家需要探索新的方法来保护我们的程序。

正是这种思维方式，加上让开发者工作更轻松的目标，促使我们开发了 WebScrapingAPI——这是一个数据提取 REST API，它能处理从代理轮换到 JavaScript 渲染以及破解 CAPTCHA 的所有环节。快来体验一下，看看 REST API 究竟能做什么吧！