关于REST API 的一些基础问题 | Postman 博客

摘录

本文翻译自 Postman 博客，原文作者为 The Postman Team。

APIs 是现代应用程序的构建块，而且在工作描述中列出“了解REST APIs”的要求变得越来越常见——即使是非开发者角色。实际上，Postman的2023年API状态报告发现，与APIs工作的人中有53%是非开发者。因此，无论你是申请成为工程师、产品经理、数据分析师还是客户成功经理，这十个关于REST API最常见面试问题的回答将帮助你自信地导航面试过程。

1. 什么是REST?

REST（Representational State Transfer，表现层状态转移）是构建Web服务和APIs最常用的架构风格。在RESTful架构中，资源通过URIs（Uniform Resource Identifiers，统一资源标识符）被识别，而通过标准的HTTP方法对这些资源进行操作。资源的状态以JSON或XML表示，这些数据在HTTP请求和响应体之间传输。

2. HTTP和REST之间的关系是什么？

HTTP（HyperText Transfer Protocol）是一种无状态的、应用层的协议，用于分布式、协作化的信息系统。它是万维网（WWW）的基础，允许Web浏览器和服务器之间传输超文本。

REST（Representational State Transfer）是一种软件架构风格，它定义了使用HTTP协议时应遵循的一系列约束条件和原则。它不是协议也不是标准，而是一种利用HTTP协议的特性，实现客户端和服务器之间轻量级交互的方法。

HTTP和REST之间的关系可以用以下几点来描述：

• 依托关系：REST架构风格依赖于HTTP协议，但它也可以应用于其他协议。HTTP为REST提供了一种可靠的通信机制，但REST架构并非专属于HTTP。
• 实现原则：REST通过HTTP方法（如GET、POST、PUT、DELETE等）实现其架构原则，如无状态通信、可缓存性、统一接口等。这些方法允许开发者定义资源的创建、查询、更新和删除操作。
• 资源导向：REST架构以资源为中心，使用URL定位资源，而HTTP提供了访问这些资源的机制。每个URL代表系统中的一个资源，HTTP方法定义了对这些资源的操作。
• 无状态通信：REST借助HTTP的无状态特性，使每个请求都包含了执行操作所需的所有信息。这降低了服务器端存储状态信息的需要，简化了应用程序的设计和实现。

总的来说，HTTP是传输层协议，提供数据传输机制，而REST是在HTTP之上构建的一种设计和架构风格，旨在简化网络通信并提高系统的可扩展性与维护性。

HTTP，即超文本传输协议，是互联网上客户端与服务器之间传输数据的主要协议。HTTP采用无状态的请求-响应模型，其中客户端向服务器发送请求，服务器相应地做出响应——而不需要了解客户端之前的请求。REST强调客户端与服务器之间标准化、无状态的交互，这使得HTTP成为实现RESTful原则的理想选择。

3. REST与SOAP的区别是什么？

REST（Representational State Transfer）和SOAP（Simple Object Access Protocol）是Web服务通信的两种主要协议。虽然它们都用于在网络上的不同系统之间发送数据，但它们在设计、功能和使用方面有显著差异。

1. 设计简便性：

   • REST是基于现有的HTTP协议，采用轻量级的方法来进行通信。它更简单、易于理解和实现。
   • SOAP是一种标准化协议，采用XML格式来定义消息格式，相对于REST，它的实现和使用更为复杂。

2. 消息格式：

   • REST可以使用多种数据交换格式，包括JSON、XML、YAML等，其中JSON因其轻量级和易于人类阅读的特性而更受欢迎。
   • SOAP仅限于XML格式，这使得消息的大小相对较大，解析速度慢。

3. 安全性：

   • REST支持多种安全性考虑，例如HTTPS、OAuth等，这些都可以在REST服务中实现。
   • SOAP内置了更强大的安全性特性，例如WS-Security，提供了身份验证和加密等功能。

4. 事务处理：

   • REST是无状态的，不保证可靠的事务处理机制。
   • SOAP支持事务处理，通过WS-AtomicTransaction来提供ACID属性（原子性，一致性，隔离性和耐久性）的事务。

5. 性能：

   • REST由于其轻量级的设计和无状态的特性，通常比SOAP具有更好的性能。
   • SOAP因其复杂性和使用XML格式的开销，性能可能比REST慢。

6. 使用场景：

   • REST由于其简单性和轻量级，适用于互联网Web服务、移动应用开发和云基础设施等。
   • SOAP由于其强大的安全性和事务处理能力，适用于在企业级应用和金融服务中的应用，需要更强大和严格安全性的场景。

综上所述，选择REST还是SOAP主要取决于应用的具体需求、数据交换格式的偏好、安全性要求和性能考虑。

REST和SOAP是构建API的两种不同的体系结构风格。REST是一种高度灵活的方法，它使用标准HTTP方法与以JSON或XML表示的资源进行交互。相比之下，SOAP是一个基于XML的消息传递协议，用于在分布式应用程序和系统之间传输数据，并且遵循非常严格的结构。虽然REST比SOAP更受欢迎，但SOAP仍然在许多需要高级安全性和错误处理功能的企业级系统中被使用。

了解更多关于 REST 与 SOAP 的区别。

4. 什么是HTTP头，最常用的有哪些？

HTTP头是HTTP请求和响应的一个组成部分，它们携带了关于客户端或服务端的附加信息，例如内容类型、响应状态等。HTTP头分为请求头和响应头，每种头都包含了多个字段，这些字段对于浏览器和服务器之间的通信至关重要。

最常用的HTTP头包括：

• Content-Type：指定了发送给接收者的实体正文的媒体类型（例如 text/html，application/json）。
• Content-Length：请求或响应正文的大小，以字节为单位。
• User-Agent：创建请求的客户端信息，比如浏览器或爬虫的类型和版本。
• Accept：客户端能够处理的媒体类型列表。
• Authorization：用于认证客户端身份的凭证。
• Cache-Control：指示缓存机制的指令，控制资源的缓存行为。
• Set-Cookie（响应头）/Cookie（请求头）：用于将状态信息传递给客户端并由客户端存储和在随后的请求中回传给服务器。
• Location（响应头）：用于重定向接收者到一个新的位置。

了解并合理使用这些HTTP头可以促进Web开发中的数据交换和状态管理，提升应用的性能和安全性。

HTTP头 包含了API请求或响应中包含的元数据。这些键-值对提供了帮助 API客户端 和服务器更有效地通信的基本细节——并使开发者能够自定义和优化API的行为。

一些最常见的请求头包括Accept，它定义了客户端能够接受的来自服务器的媒体类型；Authorization，当客户端试图访问受保护的资源时，用于向服务器发送客户端的凭据；以及Content-Type，它定义了请求体中的媒体类型。

服务器在其对客户端的响应中也包括HTTP头部。一些最常见的响应头部包括Cache-Control，它定义了响应应该如何被缓存，以及Set-Cookie，它指示客户端存储具有指定属性的cookie。

5. 在RESTful上下文中什么是资源？

一个REST资源是可以通过一个专用的API端点访问的任何对象或对象组。例如，一个简单的博客API可能有一个author资源。通过/authors/:id端点可以访问单个作者，而通过/authors端点可以访问所有作者的集合。

在一个设计良好的RESTful API中，资源及其相关的端点应遵循标准命名约定，并代表在应用程序上下文中有逻辑意义的实体。正确表示资源对于构建一个易于维护和使用的API至关重要。

6. REST APIs的一些定义特征是什么？

REST APIs具有几个促进效率、可扩展性和互操作性的特性。一个关键特性是无状态性，这意味着客户端的每个请求都包含所有必要的信息，服务器不存储任何客户端特定的数据。这种行为允许服务器处理客户端请求，而无需管理复杂的会话数据，简化了服务器设计并促进了水平扩展性。

REST APIs的另一个重要方面是客户端与服务器之间的关注点分离。REST API客户端负责用户界面和用户体验，而API服务器处理请求处理和资源管理。这种清晰的划分确保了模块性，并使每个组件能够独立发展。

最终，所有REST API都具有一个统一的界面，在这个界面中，终端通过一组既定的HTTP方法访问。这种一致性促进了API集成，因为任何支持HTTP的客户端都可以使用RESTful API——不管其平台或编程语言如何。统一的界面还使得REST API更易于维护，并加速了新用户的入门过程。

7. PUT 和 PATCH 方法之间的区别是什么？

在HTTP中，PUT和PATCH都是用于资源更新的方法，但它们在使用方式上有一定的差异：

• PUT: 它是幂等的，意味着无论执行多少次操作，结果都是相同的。使用PUT时，您需要提供目标资源的完整更新版本。如果指定的资源不存在，则PUT方法可能会创建一个新资源。

• PATCH: 与PUT不同，PATCH方法用于对资源进行部分修改。这意味着您只需发送修改部分，而不是整个资源。PATCH不是幂等的，因为多次应用同一个PATCH可能会产生不同的结果。

PUT 和 PATCH 方法都用于修改资源，但它们处理更新的方式不同。PUT 方法通过使用请求体中包含的数据来替换资源。这意味着请求体中没有包含的任何字段或属性都被删除，任何新的字段或属性都被添加。

相比之下，PATCH 方法用于对资源进行部分更新。例如，如果你有一个带有 title、year 和 rating 字段的 movie 资源，但你只想更新 rating，你可以使用 PATCH 方法发送一个仅包含 rating 字段新值的请求。资源的其余部分将保持不变。这种行为减少了必须传输的数据量，使得 PATCH 比 PUT 更高效。

8. 在RESTful上下文中，什么是幂等性？

一个HTTP方法如果无论执行多少次都会产生同样的结果，就被认为是幂等的。所有只读方法都是幂等的，PUT和DELETE也是。然而，POST和PATCH不是幂等的。POST不是幂等的，因为多次调用它将会创建多个资源。PATCH可以是幂等的，但它并不必然如此。例如，一个PATCH请求可能每次被调用时都会增加一个特定字段，这将每次都修改资源。

9. 最常见的HTTP状态码有哪些？

HTTP状态码是一个服务器用来告知客户端关于其HTTP请求处理结果的三位数字代码。下面列出了一些最常见的HTTP状态码：

• 200 OK：请求已成功处理。
• 301 Moved Permanently：请求的资源已被永久移动到新位置。
• 302 Found（历史上称为“Moved Temporarily”）：请求的资源现在临时从不同的URI响应。
• 304 Not Modified：自从上次请求后，请求的资源未被修改过。
• 400 Bad Request：服务器无法理解请求的格式。
• 401 Unauthorized：请求没有进行身份验证或者身份认证失败。
• 403 Forbidden：服务器拒绝此请求。
• 404 Not Found：服务器找不到请求的资源。
• 500 Internal Server Error：服务器遇到错误，无法完成请求。
• 502 Bad Gateway：服务器作为网关或代理，从上游服务器收到无效响应。
• 503 Service Unavailable：服务器当前无法处理请求（由于临时的过载或维护）。通常，这只是暂时状态。

这些状态码分类为五个类别（范围）：

• 1xx（信息性状态码）：服务器正在处理请求。
• 2xx（成功状态码）：请求已成功被服务器接收、理解、并接受。
• 3xx（重定向状态码）：需要客户端采取进一步的操作才能完成请求。
• 4xx（客户端错误状态码）：请求包含语法错误或无法被完成。
• 5xx（服务器错误状态码）：服务器在处理请求的过程中发生了错误。

HTTP 状态码 是服务器响应中包含的三位数字，它表明了客户端请求的结果。一些最常见的HTTP状态码包括：

200 OK: 请求成功，并且响应中包含了所请求的数据。

201 Created：请求成功，并且服务器使用提供的数据创建了一项新资源。

204 无内容：请求成功，但响应中没有额外数据发送。这个状态码经常被用于对 DELETE 请求的响应。

400 错误的请求：由于客户端错误、格式错误或无效参数，服务器无法理解请求。

401 Unauthorized（未授权）：客户端缺少访问所请求数据或执行期望操作所需的有效凭证。

403 Forbidden: 客户端没有权限访问所请求的资源，即使拥有有效的认证凭证。

404 未找到：服务器找不到所请求的资源或端点。

500 内部服务器错误：服务器遇到了一个意外的问题。

503 服务不可用：服务器未准备好处理请求，常因过载或维护。

504 网关超时: 充当网关或代理的服务器未能及时从上游服务器接收到响应。

10. Statelessness in REST的优点和缺点有哪些？

优点

1. 简化服务器设计 - 由于每个请求都是独立的，服务器不需要维护客户端的状态信息。这减少了服务器资源的使用，并简化了服务器的设计。
2. 无状态的可伸缩性 - 状态信息存储在客户端，这使得负载均衡和资源优化变得更加容易。服务器可以自由地处理来自任何客户端的请求，而无需关心之前的交互。
3. 更好的可见性 - 由于每个请求包含了所有必要的信息来处理它，中间件（如代理服务器、网关）可以更容易地理解并处理这些请求。
4. 更容易的缓存处理 - 状态无关的请求可以更容易地被缓存处理，因为响应不依赖于客户端的状态。

缺点

1. 增加了网络负载 - 由于需要在每个请求中包含所有必要的信息，这可能会增加数据的传输量，从而对网络带宽产生影响。
2. 可能降低效率 - 对于需要维持一定状态信息的应用来说，每次都需要重新传输这些信息，可能会增加延迟并降低系统的效率。
3. 安全性问题 - 更多的数据在网络中传输意味着更高的安全风险。确保数据的安全变得尤为重要，特别是当传输敏感信息时。
4. 对客户端的依赖性增加 - 客户端需要负责维护状态，这可能会增加客户端的复杂性和开发成本。

无状态是REST API的一个显著特点，它带来了许多好处。REST API服务器不需要管理会话数据，这使得它们能够处理大量的并发请求并支持水平扩展。这还导致服务器逻辑简化和响应时间加快。

无状态同样也有一些缺点。对REST API的请求可能会有更大的负载，因为客户端必须包含所有必要的信息。这可能对网络性能产生负面影响。无状态也可能要求客户端处理网络或服务器失败的情况下的重试，因为服务器端没有上下文来帮助处理这些错误场景。