1. 从“接口”到“约定”理解REST API的本质如果你在软件开发领域待过一段时间或者最近在折腾一些AI大模型、电商平台或者内容聚合服务那么“API”这个词对你来说肯定不陌生。你可能已经见过“API调用失败”、“API Key无效”或者“API接口文档”这样的字眼。而“REST API”则是这个庞大接口世界里最主流、最普遍的一种“方言”。它不像SOAP那样需要复杂的XML信封也不像GraphQL那样需要学习一套新的查询语言REST更像是一种约定俗成的“君子协定”它基于我们每天都在使用的HTTP协议用最直观的方式告诉系统“我想获取用户列表”、“我想创建一个新订单”、“我想删除这条评论”。简单来说REST API就是一套基于HTTP协议用于构建网络服务的架构风格和设计原则。它把网络上的每一个“资源”比如一个用户、一篇文章、一张图片都看作一个独立的实体然后通过HTTP方法GET、POST、PUT、DELETE等来对这些资源进行操作。这种设计让API变得非常直观和易于理解也正因为如此从社交媒体到云计算从物联网设备到如今火热的AI大模型服务比如你在热搜里看到的DeepSeek、Claude、OpenAI的APIREST API几乎无处不在。它解决了不同系统之间如何以一种标准化、无状态、可缓存的方式进行高效、可靠通信的核心问题。无论你是前端开发者需要从后端获取数据还是后端开发者需要集成第三方服务比如调用百度地图API或拼多多商品API亦或是你作为一个独立开发者想快速搭建自己的微服务理解并掌握REST API都是绕不开的一课。2. RESTful架构的六大核心约束与设计哲学为什么REST API能如此流行这背后是一套严谨的设计哲学由Roy Fielding在其博士论文中提出并归纳为六个核心约束。理解这些约束不是死记硬背概念而是掌握其设计精髓从而能设计出更健壮、更易维护的API。2.1 客户端-服务器分离这是最基本的一条。客户端比如你的手机App或浏览器和服务器提供API的后端服务是独立的。客户端只关心用户界面和用户体验不关心数据如何存储或业务逻辑服务器则专注于处理请求、执行业务逻辑和数据持久化不关心客户端是运行在iOS还是Android上。这种分离带来了巨大的好处双方可以独立进化。你可以重写整个前端界面而不影响后端也可以升级后端数据库而不必通知所有客户端。我们在调用第三方API时就完美扮演了客户端的角色我们无需知道腾讯云或阿里云服务器内部是如何运作的只需要按照它的接口规范发送请求即可。2.2 无状态这是REST设计中至关重要且容易被误解的一点。无状态意味着服务器不会在多个请求之间保存任何客户端的状态信息。每一个从客户端发往服务器的请求都必须包含处理该请求所需的全部信息。服务器不能利用之前请求存储的上下文信息。这听起来可能有点反直觉。举个例子用户登录后服务器不是会生成一个Session来记录用户已登录吗是的但RESTful方式通常不依赖服务器端的Session。更常见的做法是登录请求成功后服务器返回一个令牌Token如JWT客户端在后续的每一个需要认证的请求中都在HTTP头部如Authorization: Bearer token带上这个令牌。服务器收到请求后只需验证这个令牌的有效性即可无需去查找内存或数据库中的Session记录。为什么这么做可伸缩性由于请求包含所有信息任何服务器实例都可以处理任何请求。这使得通过简单地增加服务器数量来水平扩展变得非常容易负载均衡器可以将请求分发到任意可用的服务器上。可靠性如果某台服务器宕机不会导致用户状态丢失因为状态在客户端或令牌中。新的请求可以被其他健康的服务器无缝处理。可见性监控系统可以通过查看单个请求包就理解其完整意图便于调试和审计。注意无状态约束的是通信会话的无状态而不是应用本身不能有状态。你的数据库里当然可以存储用户数据、订单信息这些“应用状态”。REST的无状态特指“客户端会话状态”不应由服务器维护。2.3 可缓存这是提升性能的关键。服务器必须在响应中明确标识出此响应是否可被缓存以及可以缓存多久。客户端或中间的代理、网关可以根据这些指示来缓存响应数据。对于后续相同的请求可以直接从缓存中返回数据而无需再次访问服务器。HTTP协议本身为缓存提供了丰富的支持这正是REST能利用的基础Cache-Control 响应头用于定义缓存策略。例如Cache-Control: max-age3600表示此响应可以缓存1小时。ETag/If-None-Match 实体标签。服务器为资源生成一个唯一标识ETag。客户端再次请求时可带上If-None-Match: “etag_value”如果资源未变服务器返回304 Not Modified客户端使用本地缓存。Last-Modified/If-Modified-Since 基于时间的缓存验证。良好的缓存设计可以显著减少客户端-服务器之间的交互降低服务器负载并提升用户体验。例如获取城市列表、商品分类等不常变化的数据就应该设置较长的缓存时间。2.4 统一接口这是REST架构区别于其他网络架构的核心特征。它通过四个子约束来定义资源的标识每个资源如用户、文章都有一个唯一的标识符即URI统一资源标识符。例如/api/users/123标识了ID为123的用户。通过表述来操作资源客户端通过操作资源的“表述”Representation来操作资源本身。表述通常是JSON或XML格式的数据。当你向/api/users发送一个包含用户信息的JSON表述进行POST请求时你是在请求服务器创建这个资源。自描述的消息每个消息请求或响应都必须包含足够的信息来描述如何处理自己。这主要通过HTTP方法、HTTP头部和媒体类型如Content-Type: application/json来实现。看到GET /api/users和Content-Type: application/json服务器就知道客户端想获取一个JSON格式的用户列表。超媒体作为应用状态的引擎这是最理想化但也最常被忽略的一个约束简称HATEOAS。它的意思是客户端与服务器的交互完全由服务器返回的超媒体主要是链接动态驱动。客户端无需硬编码URI结构只需要知道入口点如GET /api/然后根据响应中的链接来决定下一步做什么。这使服务器可以灵活地改变URI结构而不影响客户端。虽然在实际中完全实现HATEOAS的API不多但其思想在响应中提供相关资源的链接已被广泛采纳以提升API的可发现性。2.5 分层系统架构可以被分解为若干层次每一层只与相邻的层交互。例如客户端不知道它是直接与终端服务器通信还是通过负载均衡器、代理服务器或防火墙。这种分层提高了系统的可扩展性和安全性。负载均衡器、API网关、安全层都可以作为独立的层插入而不影响客户端和服务器端的核心逻辑。2.6 按需代码这是一个可选约束。服务器可以通过向客户端传输可执行代码如JavaScript来临时扩展或定制客户端的功能。这在Web浏览器中很常见服务器返回HTMLJS但在纯粹的API交互中较少使用。大多数REST API只提供静态的数据表述JSON/XML不依赖这一特性。3. 从URI设计到状态码REST API的实操要点解析理解了理论我们来看看如何将这些原则落地设计出一个清晰、好用、不易出错的REST API。这里面的每一个选择都直接影响着开发者和最终用户的体验。3.1 资源命名与URI设计规范URI是资源的地址好的URI设计应该直观、可读、符合习惯。使用名词而非动词资源是名词操作动词由HTTP方法表达。好GET /articles获取文章列表POST /articles创建文章。不好GET /getAllArticles,POST /createArticle。使用复数形式通常对资源集合使用复数名词这样更统一。GET /users(用户集合)GET /users/101(集合中的特定用户)。层级关系表达使用路径参数表达资源间的从属关系。获取用户101的所有订单GET /users/101/orders获取用户101的订单202的详情GET /users/101/orders/202注意层级不宜过深超过两层或三层应考虑扁平化设计例如GET /orders?user_id101。过滤、排序、分页和字段选择这些不应体现在路径中而应使用查询参数Query Parameters。过滤GET /articles?statepublishedauthorjohn排序GET /articles?sort-created_at,title-表示降序分页GET /articles?page2per_page20字段选择GET /articles?fieldsid,title,excerpt只返回指定字段提升性能3.2 HTTP方法的语义化使用HTTP方法是REST API的“动词”必须严格按照其语义使用。GET 安全且幂等的。用于获取资源或其集合。不应改变服务器状态。POST 非安全非幂等。用于创建新资源。通常响应状态码为201 Created并在Location头部返回新资源的URI。PUT 非安全但幂等。用于完整更新一个已知资源。客户端需要提供更新后的完整资源表述。如果资源不存在某些设计允许用PUT创建需明确约定。PATCH 非安全但幂等。用于部分更新一个资源。客户端只发送需要改变的字段。这是与PUT的主要区别。DELETE 非安全但幂等。用于删除一个资源。HEAD 类似于GET但只返回响应头不返回响应体。用于检查资源是否存在或获取元数据。OPTIONS 用于获取目标资源所支持的通信选项支持的HTTP方法等。幂等性是一个重要概念无论相同的操作执行一次还是多次产生的效果是一样的。GET、PUT、DELETE是幂等的POST不是。这意味着网络超时后客户端可以安全地重试幂等请求。3.3 HTTP状态码请求结果的“语言”状态码是服务器向客户端报告请求处理结果最直接的方式。正确使用状态码能让客户端准确判断下一步该做什么。2xx 成功200 OK 通用成功状态。用于GET、PUT、PATCH或DELETE的成功响应。201 Created资源创建成功。必须在POST创建资源成功后返回。响应头Location应包含新资源的URI。204 No Content 请求成功但响应体无内容。常用于DELETE成功或PUT/PATCH更新后无需返回资源详情时。3xx 重定向301 Moved Permanently 资源URI已永久变更。304 Not Modified 资源未修改用于缓存验证。4xx 客户端错误责任在客户端。400 Bad Request通用客户端错误。服务器无法理解请求格式如JSON语法错误、缺少必要参数或参数无效。你在热搜里看到的‘type’ must be in [“enabled”, “disabled”, “auto”]和maximum context length错误通常都会以400状态码返回并在响应体中给出具体错误信息。401 Unauthorized未认证。请求需要用户认证但未提供有效的认证凭证如Token过期或错误。403 Forbidden已认证但无权限。服务器理解请求但拒绝执行如普通用户试图删除管理员文章。404 Not Found资源不存在。请求的URI无法映射到任何资源。405 Method Not Allowed 请求行中指定的方法不被该URI支持。应在响应头Allow中列出支持的方法。409 Conflict 请求与服务器当前状态冲突如创建资源时唯一键冲突。429 Too Many Requests请求过于频繁触发速率限制。这是API服务商保护服务器的常见手段。5xx 服务器错误责任在服务器。500 Internal Server Error 通用服务器错误。这是服务器端的“黑盒”表明发生了未预期的错误。502 Bad Gateway、503 Service Unavailable、504 Gateway Timeout 通常与网关、代理或后端服务不可用有关。实操心得永远不要用200 OK来包装一个业务逻辑错误如“用户名已存在”。这会让客户端处理逻辑变得复杂。正确的做法是验证失败返回400并给出具体错误字段权限不足返回403资源冲突返回409。让HTTP状态码承担起它应有的语义责任。3.4 请求与响应体的设计规范请求体 对于POST、PUT、PATCH请求通常使用JSON格式。确保设置正确的Content-Type: application/json头部。创建资源 POST请求体应包含创建资源所需的所有字段。更新资源 PUT需要完整资源表述PATCH只需包含需要更新的字段可以使用JSON Patch标准格式但更常见的是使用简单的部分JSON对象。响应体 同样推荐使用JSON作为主要格式。响应体设计应保持一致性和可预测性。成功响应 直接返回资源对象或资源列表。对于列表通常会包装在一个包含分页信息的对象中。{ data: [...], // 资源数组 pagination: { page: 1, per_page: 20, total: 150, total_pages: 8 } }错误响应 必须提供机器可读且人类可理解的错误信息。一个良好的错误响应格式应包含{ error: { code: invalid_parameter, // 错误代码用于程序判断 message: ‘type’ must be in [‘enabled‘, ‘disabled‘, ‘auto‘], // 给人看的描述 field: type, // 可选哪个字段出错 details: {...} // 可选更详细的上下文信息 } }这正是处理类似热搜中API error: 400 ‘type‘ must be in [“enabled”, “disabled”, “auto”]这类问题的标准做法。4. 构建一个完整的REST API服务从设计到实现让我们以一个简单的“任务管理”API为例串联起上述所有要点看看一个完整的REST API是如何从设计到实现的。4.1 需求分析与资源建模假设我们需要一个API来管理用户的待办任务Todo。核心实体是“任务”Task。每个任务有ID、标题、描述、完成状态、创建时间等属性。用户可以对任务进行增删改查。根据REST原则我们将“任务”视为资源。资源集合的URI是/tasks单个资源的URI是/tasks/{id}。4.2 API端点设计与文档首先我们定义出清晰的API端点Endpoint规范。这是前后端、甚至不同团队之间的契约。HTTP方法URI描述成功状态码GET/tasks获取任务列表支持分页、过滤200 OKPOST/tasks创建一个新任务201 CreatedGET/tasks/{id}获取指定ID的任务详情200 OKPUT/tasks/{id}完整更新指定ID的任务200 OK / 204 No ContentPATCH/tasks/{id}部分更新指定ID的任务如标记完成200 OK / 204 No ContentDELETE/tasks/{id}删除指定ID的任务204 No Content4.3 使用Node.js与Express框架快速实现我们选择Node.js的Express框架因为它轻量且非常适合构建REST API。1. 项目初始化与依赖安装mkdir todo-api cd todo-api npm init -y npm install express2. 基础服务器与应用数据创建server.js文件const express require(express); const app express(); const PORT process.env.PORT || 3000; // 中间件解析JSON格式的请求体 app.use(express.json()); // 内存中的“数据库”用于演示 let tasks [ { id: 1, title: 学习REST API, description: 阅读Fielding的论文, completed: false, createdAt: new Date() }, { id: 2, title: 购买 groceries, description: 牛奶、鸡蛋、面包, completed: true, createdAt: new Date() } ]; let nextId 3; // 启动服务器 app.listen(PORT, () { console.log(REST API server running at http://localhost:${PORT}); });3. 实现GET /tasks获取列表// GET /tasks - 获取任务列表带分页和过滤 app.get(/tasks, (req, res) { let result [...tasks]; // 过滤根据查询参数 completed 过滤 if (req.query.completed ! undefined) { const isCompleted req.query.completed true; result result.filter(task task.completed isCompleted); } // 排序根据查询参数 sort 排序默认按创建时间降序 const sortField req.query.sort || -createdAt; const [field, order] sortField.startsWith(-) ? [sortField.slice(1), -1] : [sortField, 1]; if ([id, title, createdAt].includes(field)) { result.sort((a, b) (a[field] b[field] ? order : -order)); } // 分页 const page parseInt(req.query.page) || 1; const perPage parseInt(req.query.per_page) || 10; const startIndex (page - 1) * perPage; const paginatedResult result.slice(startIndex, startIndex perPage); // 构建符合HATEOAS思想的响应包含分页信息和链接 const total result.length; const totalPages Math.ceil(total / perPage); const response { data: paginatedResult, pagination: { page, per_page: perPage, total, total_pages: totalPages }, links: { self: /tasks?page${page}per_page${perPage}, first: /tasks?page1per_page${perPage}, last: totalPages 0 ? /tasks?page${totalPages}per_page${perPage} : null, prev: page 1 ? /tasks?page${page - 1}per_page${perPage} : null, next: page totalPages ? /tasks?page${page 1}per_page${perPage} : null, } }; res.status(200).json(response); });4. 实现POST /tasks创建任务// POST /tasks - 创建新任务 app.post(/tasks, (req, res) { // 1. 验证请求体 const { title, description } req.body; if (!title || typeof title ! string || title.trim() ) { // 返回400错误包含详细错误信息 return res.status(400).json({ error: { code: validation_failed, message: Title is required and must be a non-empty string., field: title } }); } // 2. 创建新任务对象 const newTask { id: nextId, title: title.trim(), description: description ? description.trim() : , completed: false, createdAt: new Date(), updatedAt: new Date() }; // 3. 保存到“数据库” tasks.push(newTask); // 4. 返回201 Created并在Location头部提供新资源的URI res.setHeader(Location, /tasks/${newTask.id}); res.status(201).json({ data: newTask, links: { self: /tasks/${newTask.id}, all: /tasks } }); });5. 实现GET /tasks/{id}获取单个任务// GET /tasks/:id - 获取单个任务 app.get(/tasks/:id, (req, res) { const taskId parseInt(req.params.id); const task tasks.find(t t.id taskId); if (!task) { return res.status(404).json({ error: { code: not_found, message: Task with ID ${taskId} was not found. } }); } res.status(200).json({ data: task, links: { self: /tasks/${taskId}, collection: /tasks } }); });6. 实现PATCH /tasks/{id}部分更新// PATCH /tasks/:id - 部分更新任务 app.patch(/tasks/:id, (req, res) { const taskId parseInt(req.params.id); const taskIndex tasks.findIndex(t t.id taskId); if (taskIndex -1) { return res.status(404).json({ error: { code: not_found, message: Task not found. } }); } const updates req.body; const allowedUpdates [title, description, completed]; const isValidUpdate Object.keys(updates).every(key allowedUpdates.includes(key)); if (!isValidUpdate) { return res.status(400).json({ error: { code: invalid_update, message: Only ${allowedUpdates.join(, )} fields can be updated., invalid_fields: Object.keys(updates).filter(k !allowedUpdates.includes(k)) } }); } // 执行更新 tasks[taskIndex] { ...tasks[taskIndex], ...updates, updatedAt: new Date() // 更新修改时间 }; // 返回更新后的资源 res.status(200).json({ data: tasks[taskIndex], links: { self: /tasks/${taskId}, collection: /tasks } }); });7. 实现DELETE /tasks/{id}删除任务// DELETE /tasks/:id - 删除任务 app.delete(/tasks/:id, (req, res) { const taskId parseInt(req.params.id); const initialLength tasks.length; tasks tasks.filter(t t.id ! taskId); if (tasks.length initialLength) { // 没有任务被删除说明ID不存在 return res.status(404).json({ error: { code: not_found, message: Task not found. } }); } // 删除成功返回204 No Content无响应体 res.status(204).send(); });4.4 测试你的API使用工具如cURL、Postman或Thunder Client来测试上述API。获取列表GET http://localhost:3000/tasks?completedfalsesort-createdAtpage1per_page5创建任务POST http://localhost:3000/tasks Body (JSON):{title: New REST Task, description: Test creation}更新任务PATCH http://localhost:3000/tasks/1 Body:{completed: true}删除任务DELETE http://localhost:3000/tasks/25. 进阶话题与生产环境实践一个能用于演示的API和一个能用于生产环境的API之间存在着巨大的鸿沟。以下是你在构建真实服务时必须考虑的几个关键方面。5.1 认证与授权无状态的REST API通常使用基于令牌的认证。JWT 最流行的方案。用户登录后服务器用密钥生成一个签名的Token包含用户ID、过期时间等客户端后续在Authorization: Bearer token头部携带。服务器无需查库即可验证。注意JWT一旦签发在过期前无法撤销对于敏感操作需结合短期Token或黑名单机制。OAuth 2.0 用于第三方授权如“使用微信登录”。它定义了授权码、客户端凭证等多种流程是开放平台API如GitHub API、Google API的标准。API Keys 简单但安全性较低常用于机器对机器的通信或对安全性要求不高的场景。密钥通常放在请求头或查询参数中。授权通常在认证之后决定用户能做什么。常用模型有RBAC基于角色的访问控制或ABAC基于属性的访问控制。在每一个需要权限的端点处理函数中你都需要检查当前用户是否有权操作目标资源。5.2 速率限制与API配额为了防止滥用和保证服务稳定必须实施速率限制。令牌桶算法或漏桶算法是常见实现。实现层面可以使用中间件根据客户端IP或API Key在Redis等内存数据库中记录请求计数和时间窗口。通信方式在响应头中告知客户端限制情况这是良好实践。X-RateLimit-Limit: 100 // 时间窗口内允许的最大请求数 X-RateLimit-Remaining: 95 // 当前窗口剩余请求数 X-RateLimit-Reset: 1640995200 // 窗口重置的Unix时间戳当超出限制时返回429 Too Many Requests状态码。5.3 版本管理API一旦发布客户端就会依赖它。但业务需求总会变化。如何在不破坏现有客户端的情况下更新API答案是版本化。URI路径版本化 最直观的方式如/api/v1/tasks,/api/v2/tasks。请求头版本化 通过自定义Header指定版本如Accept: application/vnd.myapi.v1json。这种方式更符合REST原则但实现稍复杂。查询参数版本化 如/tasks?version1不推荐用于主要版本可能影响缓存。策略 维护旧版本一段时间并在文档中明确其弃用时间表引导用户迁移到新版本。5.4 文档、测试与监控文档 API没有文档就等于不存在。使用OpenAPI (Swagger)规范来编写机器可读的API定义文件YAML/JSON然后利用Swagger UI或Redoc等工具自动生成美观的交互式文档页面。这能极大提升开发者体验。测试 除了单元测试必须进行API集成测试。使用SupertestNode.js、PytestPython等框架模拟各种请求正常、异常、边界情况确保端点行为符合预期。监控与日志 在生产环境中你需要记录详细的访问日志和错误日志。监控关键指标请求量、响应时间、错误率特别是4xx和5xx、端点吞吐量。使用APM工具来追踪慢请求和性能瓶颈。当出现热搜中类似API error: 529 overloaded或500 internal server error时完善的日志和监控是你快速定位问题的唯一依靠。6. 常见“坑”与最佳实践避坑指南在实际开发和集成API的过程中你会遇到各种各样的问题。以下是一些高频“坑点”及其解决方案。6.1 客户端常见错误处理很多API调用错误源于客户端使用不当。以下是一个排查清单错误现象可能原因排查步骤与解决方案400 Bad Request1. 请求体JSON格式错误。2. 缺少必需字段或字段类型错误。3. 参数值不符合枚举范围如热搜中的‘type’ must be in [“enabled”, “disabled”, “auto”]。1. 使用JSON验证工具检查请求体语法。2. 仔细阅读API文档确认字段名、类型、是否必填。3. 检查错误响应体通常服务器会指明哪个字段出错。401 Unauthorized1. 未提供认证信息API Key, Token。2. Token已过期。3. Token格式错误。1. 确认请求头通常是Authorization已正确设置。2. 检查Token是否在有效期内必要时重新获取。3. 确认Token前缀如Bearer是否正确。403 Forbidden已认证但权限不足。确认当前使用的账号/Token拥有执行该操作所需的权限角色或范围。404 Not Found1. URI拼写错误。2. 资源ID不存在。1. 逐字核对API文档中的端点路径。2. 确认你要操作的资源ID是否有效且属于当前用户。429 Too Many Requests触发了API的速率限制。1. 降低请求频率实现请求间隔或队列。2. 检查响应头中的X-RateLimit-Reset等待窗口重置。3. 如需更高配额联系API提供方。5xx系列错误服务器内部错误。1.首先停止疯狂重试这可能会加重服务器负担。2. 稍后重试并采用指数退避策略。3. 如果是集成第三方API查看其服务状态页。网络超时/连接错误1. 网络不稳定。2. 服务器未响应。3. 客户端请求配置超时时间太短。1. 检查本地网络。2. 增加客户端的请求超时设置如从5秒调到30秒。3. 实现重试机制并对非幂等操作POST要格外小心。6.2 服务器端设计陷阱N1查询问题 在返回资源列表时如果每个资源都需要关联其他数据如作者信息在循环中单独查询会导致数据库查询次数暴增。务必使用预加载或批量查询来优化。过度获取与不足获取 这是API设计中的经典矛盾。客户端可能需要不同的数据字段组合。解决方案是使用字段选择如?fieldsid,title或采用GraphQL它专门解决此类问题但复杂度更高。忽略HTTP缓存 对于变动不频繁的只读资源如国家列表、配置信息一定要设置合适的Cache-Control和ETag头部可以极大减轻服务器压力。脆弱的客户端 客户端代码如果硬编码了API的URI结构一旦服务器端URI改变所有客户端都会崩溃。尽量让客户端依赖HATEOAS链接或者至少将API的基础URL配置化。6.3 安全性考量HTTPS是必须的 任何生产环境的API都必须使用HTTPS以防止中间人攻击和数据泄露。输入验证与净化 永远不要信任客户端传来的数据。对所有输入进行严格的验证类型、长度、范围、格式和净化防止SQL注入、XSS攻击。敏感信息保护 不要在URL、日志或响应体中暴露敏感信息如数据库ID、内部错误详情、用户密码。使用混淆的公共ID如UUID替代自增ID。CORS配置 如果你的API需要被浏览器端JavaScript调用必须正确配置CORS头部明确允许的来源、方法和头部而不是简单地设为*。构建和维护一个高质量的REST API是一个持续的过程它涉及严谨的设计、清晰的文档、全面的测试和持续的监控。从简单的CRUD接口到支撑亿万级流量的平台核心其背后的原则是相通的。理解并践行这些原则你设计的API将不仅仅是能工作的接口更是稳定、可扩展、易于协作的数字化基石。