后端与系统架构6292 字

Restful API设计最佳实践

·全库 566 / 611

《Restful API设计最佳实践》共 0.6 万字,通篇围绕 安全、检索、日志、缓存 展开,归在「后端与系统架构」这一层。

覆盖安全检索日志缓存架构MySQL

适合给 AI 系统搭底座、要管得住的人

目录骨架(8 节)
  1. 1.什么是 REST API?
  2. 2.REST API 设计建议
  3. 3.一个文章API设计
  4. 4.REST API常见问题
  5. 5.小结
  6. 1. 用名词表示资源
  7. 2. 用复数名词表示集合
  8. 3. 端点使用嵌套显示关系

本次分享内容

  1. REST API介绍
  2. REST API设计建议:资源命名、参数传递、错误状态、版本划分等
  3. 一个文章API的设计案例
  4. REST API常见问题

1.什么是 REST API?

REST API 是当今最常见的 Web 接口形式之一 ,在确保客户端和服务器之间的顺利通信方面发挥了重要作用。

你可以把客户端看作前端,把服务器看作后端。

客户端(前端)和服务器(后端)之间的通信通常不是直接的。因此,我们使用 API(应用编程接口),作为客户端和服务器之间的中介。

因为 API 在这种 client–server 通信中起着至关重要的作用,所以我们在设计 API 时应该遵循最佳实践。这有助于开发人员更好地维护和使用它们。

本次讲解创建 REST API 时可以遵循的一些最佳实践。这将帮助大家创建高效,安全,易于使用和维护的 API。

  1. 什么是 REST API?

REST 是 Representational State Transfer 的缩写。它是由 Roy Fielding 博士在 2000 年他的博士论文中提出一种软件架构风格,用于指导网络应用的设计和开发,使得 Web API(网络应用编程接口)更加简单、灵活、可扩展和易于理解。

任何遵循 REST 设计原则的 API 都被称为 RESTful API。

简单地说,REST API 是两台计算机通过 HTTP(超文本传输协议)进行通信的媒介,与客户端和服务器的通信方式相同。

REST API 使用 URL 唯一标识和定位 RESTful 服务中的资源,一个完整的 URL 结构如下:

2.REST API 设计建议

1. 用名词表示资源

当你设计一个 REST API 时,端点应该使用名词而非动词。

这是因为 HTTP 方法已经以动词形式执行基本的 CRUD(创建、读取、更新、删除)操作。

GET、POST、PUT、PATCH 和 DELETE 是最常见的 HTTP 动词。还有其他非 HTTP 标准动词,如 COPY、PURGE、LINK、UNLINK 等等。

因此,举例来说,一个端点不应该是这样的:

https://mysite.com/getPosts
https://mysite.com/createPost

它应该是这样的:

https://mysite.com/posts

2. 用复数名词表示集合

如果 URL 表示的资源是一个集合应该使用复数名词。

如果你有一个像 https://mysite.com/post/123 这样的端点,用 DELETE 请求删除一个帖子,或用 PUT 或 PATCH 更新一个帖子,可能是可以的,但它没有告诉用户在这个集合中可能还有一些其他帖子。这就是为什么你的集合应该使用复数的名词。

所以,不应该是 https://mysite.com/post/123,而是 https://mysite.com/posts/123。

3. 端点使用嵌套显示关系

很多时候,不同的端点相互联系,所以你应该对它们进行嵌套,这样更容易理解它们。

例如,对于一个多用户博客平台,不同的帖子可能是由不同的作者写的,所以在这种情况下,像 https://mysite.com/posts/author 这样的端点会成为一个有效的嵌套。

同样地,帖子可能有各自的评论,所以要检索评论,可以使用 https://mysite.com/posts/{postId}/comments 这样的端点。

你应该避免超过 3 层的嵌套,因为这可能使 API 不那么优雅,降低可读性。

4. 用 HTTP 方法操作资源

使用 URL 指定你要用的资源。使用 HTTP 方法来指定怎么处理这个资源。使用五种 HTTP 方法 POST,GET,PUT/PATCH,DELETE 可以提供 CRUD 功能(创建,获取,更新,删除)。

除了 POST 其他请求都具备幂等性(多次请求的效果相同)。需要注意的是 POST 和 PUT 最大的区别就是幂等性,所以 PUT 也可以用于创建操作,只要在创建前就可以确定资源的 ID。

  • 获取:使用 GET 方法获取资源。GET 请求从不改变资源的状态。无副作用。GET 是幂等的。GET 具有只读的含义。因此,你可以完美的使用缓存。
  • 创建:使用 POST 创建新的资源(非幂等)。
  • 更新:使用 PUT 更新整个资源,PATCH 更新资源部分信息。PUT 和 PATCH 都是幂等的。
  • 删除:使用 DELETE 删除现有资源(幂等)。

简而言之,你应该让 HTTP 动词来处理端点的工作。因此,GET 将检索资源,POST 将创建资源,PUT 将更新整个资源,DELETE 将删除资源,PATCH 更新资源的局部数据。

资料里没有你的场景?

把你手上的数据和想解决的那个环节发上来,我们按具体情况回,不复述方法论。

发布需求