17370845950

REST API 是一套设计风格约定，核心是用 URL 标识资源、HTTP 方法表达操作（GET/POST/PUT/PATCH/DELETE）、JSON 为常用数据格式；JavaScript 通过 fetch 或 XMLHttpRequest 发送请求，需正确设置 headers（如 Content-Type）、处理响应状态与 JSON 解析，并注意 CORS 预检限制。

REST API 不是一种工具或框架，而是一套设计风格约定；JavaScript 与它交互的核心就是发送 HTTP 请求并处理响应，关键在于理解 fetch 或 XMLHttpRequest 如何映射 REST 的资源操作（GET/POST/PUT/DELETE）。

REST API 的本质是 URL + HTTP 方法 + 数据格式

它把后端能力抽象成“资源”，每个资源有唯一 URL，用标准 HTTP 方法表达意图：

• GET /users → 获取用户列表（不修改服务端状态）
• POST /users → 创建新用户（提交数据，服务端生成 ID）
• GET /users/123 → 获取 ID 为 123 的用户
• PUT /users/123 → 完整替换该用户信息（需传全部字段）
• PATCH /users/123 → 局部更新（如只改邮箱）
• DELETE /users/123 → 删除该用户

实际请求中，Content-Type 头通常设为 application/json，请求体和响应体也多为 JSON 格式。

用 fetch 发送 GET 请求并解析 JSON

这是最常见场景，但容易忽略错误处理和响应状态检查：

fetch('https://jsonplaceholder.typicode.com/posts/1')
  .then(response => {
    if (!response.ok) {
      throw new Error(`HTTP error! status: ${response.status}`);
    }
    return response.json();
  })
  .then(data => console.log(data.title))
  .catch(err => console.error('Fetch failed:', err));

• response.ok 判断是否为 2xx 状态，fetch 不会因 4xx/5xx 拒绝 Promise
• response.json() 返回 Promise，不能直接在 .then() 里当同步函数用
• 若后端返回非 JSON（比如 HTML 错误页），.json() 会抛出语法错误

用 fetch 发送 POST 请求并设置请求头

漏掉 Content-Type 或没 JSON.stringify 是高频失败原因：

const user = { name: 'Alice', email: 'alice@example.com' };

fetch('https://jsonplaceholder.typicode.com/users', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json'
  },
  body: JSON.stringify(user)
})
.then(res => res.json())
.then(data => console.log('Created:', data.id))
.catch(err => console.error(err));

• body 必须是字符串、FormData 或 Blob，对象直接传会报错
• headers 中的 Content-Type 告诉服务端如何解析 body
• 有些 API 要求额外 header，比如认证用的 Authorization: Bearer

CORS 和预检请求（OPTIONS）为什么突然失败

浏览器对跨域请求有严格限制，不是后端返回 200 就算成功：

• 带自定义 header（如 Authorization）或非简单方法（PUT/DELETE）会触发预检请求
• 预检失败时，控制台显示 Failed to fetch，但 Network 面板能看到 OPTIONS 请求返回 403 或无 Access-Control-Allow-Origin
• 前端无法绕过该限制——必须后端在响应头中显式允许，例如：Access-Control-Allow-Origin: * 或指定域名
• 开发时可用本地代理（如 vite.config.ts 中的 server.proxy）规避 CORS，而非禁用浏览器安全策略

真正难调试的往往不是代码写错，而是没看清 Network 面板里哪一栏标红、哪个请求被拦截、响应头缺了什么字段。