Loop`s Workshop

Appearance

RESTful API ​

1. REST 的本质 ​

REST (Representational State Transfer，表述性状态转移) 不是某个标准，而是一种 架构风格。
它的核心思想是：

  • 把一切都抽象为资源（Resource）

  • 资源通过 URI 定位

  • 资源的操作用 HTTP 动词表达（GET/POST/PUT/DELETE...）

  • 资源的状态通过表述（Representation，比如 JSON/XML）在客户端和服务端之间传递

2. RESTful API 的特点 ​

  1. 统一接口（Uniform Interface）

    • 例如：

      • GET /users → 获取用户列表

      • GET /users/1 → 获取 ID=1 的用户

      • POST /users → 创建用户

      • PUT /users/1 → 更新用户

      • DELETE /users/1 → 删除用户

  2. 无状态（Stateless）

    • 每次请求必须包含所有必要信息（认证、参数等）。

    • 服务端不会记住客户端的状态。

  3. 可缓存（Cacheable）

    • GET 请求结果可缓存，提升性能。

  4. 分层系统（Layered System）

    • 可以在客户端和服务端之间加缓存、代理、网关，而不会破坏接口设计。

3. 优点 ​

  • 统一风格：简单直观，URL 本身表达语义，降低学习成本。

  • 良好兼容性：基于 HTTP 协议，天然支持缓存、代理、负载均衡。

  • 资源化思维：使 API 设计更有条理，接近 CRUD 模型。

4. 局限 / 不足 ​

  • 对复杂场景表达力不足：
    比如需要批量操作、多资源聚合查询（典型场景：前端一个页面需要多个 REST 请求）。

  • 过度依赖约定：
    如果团队没有很好地遵循 REST 设计规范，就容易变成“伪 REST”。

  • 前后端通信效率问题：
    前端可能需要多次调用不同接口才能拼出一个页面数据，这时候 GraphQL/JSON:API 会更优。

  • 版本管理难：
    REST API 一旦发布，修改接口容易破坏兼容性，所以常见 v1/v2 版本号出现在 URL 中。

HTTP:不同请求方法的区别 ​

请求方法向服务器描述了客户端发出请求的动作类型。

HTTP只是协议，不同请求方法只是在语义层面有区别，但服务器和浏览器通常有一些约定俗成的规范行为，使得不同请求方法区别很大。

请求方法也是可以自定义的,只需要改Header里的method，但是一般不会这么用😂

  • GET: 请求资源，无需请求体

    • 从技术上，HTTP 标准文档规定GET是可以携带请求体的
    • 从标准和行业规范上，GET请求不应该携带请求体，一些浏览器会忽略Body

  • POST: 提交数据, 带请求体

  • PUT: 修改数据, 带请求体

  • DELETE: 删除数据, 无需请求体

  • OPTIONS: 在跨域请求时，浏览器会先发送OPTIONS请求(预检请求)，询问服务器是否允许跨域

  • TRACE: 用于测试或诊断，服务器会返回请求的完整路径

  • CONNECT

具体一些，GET与POST的区别 ​

和上文一样，本质是语义层面的区别，但服务器与浏览器通常有约定俗成的规范行为，造成了区别。

  1. 浏览器发送GET时，不会附带Body,如果你自己用个Node去发，那想带就带
  2. GET用请求参数携带信息，数据量受浏览器限制，POST放Body自然没有限制
  3. GET只能传ASCII数据，现代浏览器会自动进行URL-Encoding
  4. GET请求信息会暴露在URL中，所以敏感信息不要用GET，用POST
  5. GET请求会被浏览器缓存，可以添加到书签完整复现