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 渲染以及破解验证码等所有环节。快来体验一下，看看 REST API 究竟能做什么吧！