本文旨在阐述使用 REST API 相较于简易方法（如直接处理 $_POST 参数并输出 json）的优势。我们将探讨 CORS 头部的重要性、如何使用 Fetch API 获取 JSON 结果，以及为何在现代系统中 Grpc 通常优于 SOAP。通过本文，你将了解如何构建更安全、更规范、更易于维护的 API。
在构建 Web API 时，开发者常常面临多种选择。一种常见的简易方法是直接读取 $_POST 或 $_GET 参数，执行数据库操作，然后使用 json_encode 将结果输出。虽然这种方法简单快捷，但存在诸多局限性，尤其是在安全性、可扩展性和标准化方面。采用 restful API 架构可以有效解决这些问题。
CORS 头部：保障 API 安全的关键
CORS（Cross-Origin Resource Sharing）头部是 REST API 中至关重要的安全机制。它允许服务器声明哪些源（域、协议和端口）可以访问其资源。如果没有 CORS 头部，浏览器会阻止跨域请求，从而保护用户免受潜在的恶意攻击。
例如，如果你的 API 部署在 api.example.com 上，而你的网站部署在 www.example.com 上，当你的网站尝试通过 JavaScript 的 fetch 或 xmlhttpRequest 向 API 发送请求时，浏览器会检查 API 的 CORS 头部。如果 API 没有设置 Access-Control-Allow-Origin 头部，或者该头部的值不允许 www.example.com 访问，浏览器就会阻止该请求。
以下是一个 php 示例，展示如何设置 CORS 头部：
<?php header("Access-Control-Allow-Origin: https://www.example.com"); header("Content-Type: application/json; charset=UTF-8"); header("Access-Control-Allow-Methods: POST, GET, OPTIONS"); header("Access-Control-Allow-Headers: Content-Type, Authorization"); // ... API 处理逻辑 ... echo json_encode($response);
- Access-Control-Allow-Origin: 指定允许访问 API 的源。可以使用 * 允许所有源，但出于安全考虑，强烈建议只允许特定的源。
- Content-Type: 指定响应的内容类型为 JSON。
- Access-Control-Allow-Methods: 指定允许的 HTTP 方法，如 POST、GET、OPTIONS。
- Access-Control-Allow-Headers: 指定允许的请求头部，如 Content-Type、Authorization。
注意事项：
- 在生产环境中，务必将 Access-Control-Allow-Origin 设置为特定的域名，避免使用 *。
- OPTIONS 方法用于预检请求，浏览器会在实际请求之前发送一个 OPTIONS 请求，以检查服务器是否允许该跨域请求。
使用 Fetch API 获取 JSON 数据
fetch API 是现代 JavaScript 中用于发起网络请求的标准方法。它可以轻松地与 REST API 集成，获取 JSON 数据。
以下是一个使用 fetch API 获取 JSON 数据的示例：
fetch('https://api.example.com/data', { method: 'GET', headers: { 'Accept': 'application/json', 'Content-Type': 'application/json' } }) .then(response => { if (!response.ok) { throw new Error('Network response was not ok'); } return response.json(); }) .then(data => { console.log(data); // 处理 JSON 数据 }) .catch(error => { console.error('There was a problem with the fetch operation:', error); });
- Accept: 指定客户端期望接收的内容类型为 JSON。
- Content-Type: 指定请求的内容类型为 JSON（如果发送请求体）。
- response.json(): 将响应体解析为 JSON 对象。
注意事项：
- 确保 API 响应的 Content-Type 头部设置为 application/json。
- 处理 fetch 操作中的错误，例如网络错误或 API 返回的错误状态码。
SOAP vs. GRPC：现代 API 的选择
SOAP（Simple Object Access Protocol）是一种基于 XML 的协议，用于在计算机之间交换结构化信息。虽然 SOAP 在过去被广泛使用，但现在已经逐渐被 REST 和 GRPC 等更现代的 API 架构所取代。
GRPC（gRPC Remote Procedure Call）是一种高性能、开源的通用 RPC 框架，由 Google 开发。它使用 Protocol Buffers 作为接口定义语言，支持多种编程语言，并提供高效的二进制序列化和传输。
为什么 GRPC 通常优于 SOAP？
- 性能： GRPC 使用 HTTP/2 作为传输协议，支持多路复用、头部压缩等特性，从而提高了性能。
- 效率： GRPC 使用 Protocol Buffers 进行序列化，比 XML 更高效。
- 类型安全： Protocol Buffers 提供强类型支持，可以减少错误。
- 代码生成： GRPC 提供了代码生成工具，可以自动生成客户端和服务器端的代码。
总结：
使用 REST API 相较于简易方法，可以提高 API 的安全性、可扩展性和标准化程度。CORS 头部是保障 API 安全的关键，fetch API 可以轻松地获取 JSON 数据。在选择 API 架构时，GRPC 通常优于 SOAP，因为它提供了更高的性能和效率。通过采用这些最佳实践，你可以构建更健壮、更易于维护的 Web API。
