RESTful API是一套设计风格，核心是URL仅表示资源（名词），HTTP方法表达操作意图；用fetch时需手动设置headers和JSON.stringify body，且须检查response.ok处理HTTP错误。
RESTful API 不是一种协议或标准，而是一套设计风格和约束条件；它本身不提供任何功能，关键在于你如何用 JavaScript 正确发起符合 REST 原则的请求。
什么是 RESTful API：看 HTTP 方法和资源路径是否匹配
判断一个接口是不是 RESTful，核心就两点：URL 只表示资源（名词），HTTP 方法表达操作意图。比如：
-
GET /users→ 获取用户列表（不是GET /getUsers） -
POST /users→ 创建新用户（不是POST /addUser） -
PUT /users/123→ 完整更新 ID 为 123 的用户 -
PATCH /users/123→ 局部更新（如只改邮箱） -
DELETE /users/123→ 删除该用户
如果后端把操作写进路径（如 /api/deleteUser?id=123），哪怕用了 JSON 返回，也不是 RESTful —— 这只是“带参数的 HTTP 接口”。
用 fetch 发起 RESTful 请求：别漏掉 method、headers 和 body
JavaScript 中最常用的是 fetch，但它默认不发 Content-Type: application/json，也不自动序列化对象，容易导致后端收不到数据。
立即学习“Java免费学习笔记（深入）”；
常见错误示例：
fetch('/users', {
method: 'POST',
body: { name: 'Alice' } // ❌ 错误：body 是对象，但没转成 JSON，也没设 headers
});
正确写法：
fetch('/users', {
method: 'POST',
headers: {
'Content-Type': 'application/json'
},
body: JSON.stringify({ name: 'Alice', email: 'alice@example.com' })
})
.then(r => r.json())
.then(data => console.log(data));
注意点：
-
GET请求不能带body，参数应拼在 URL 后（?page=2&limit=10）或用URLSearchParams -
PUT/PATCH更新时，确保传的是完整资源或明确的字段变更（取决于后端约定） - 401/403 错误往往是因为没带
Authorizationheader，比如'Authorization': 'Bearer'
处理响应与错误：别只依赖 .then() 链
fetch 在网络失败时才 reject，而 HTTP 状态码如 404、500 仍会进入 .then()。必须手动检查 response.ok 或 response.status。
AJAX即“Asynchronous Javascript And XML”（异步JavaScript和XML），是指一种创建交互式网页应用的网页开发技术。它不是新的编程语言，而是一种使用现有标准的新方法，最大的优点是在不重新加载整个页面的情况下，可以与服务器交换数据并更新部分网页内容，不需要任何浏览器插件，但需要用户允许JavaScript在浏览器上执行。《php中级教程之ajax技术》带你快速
推荐写法：
fetch('/users/999')
.then(response => {
if (!response.ok) {
throw new Error(`HTTP error! status = ${response.status}`);
}
return response.json();
})
.then(data => console.log(data))
.catch(err => console.error('请求失败:', err.message));
容易忽略的问题：
-
response.json()本身可能抛错（返回非 JSON 内容时），建议加 try/catch 包裹 - 某些后端对空 body 的
POST返回204 No Content，此时调response.json()会报错，需先判断response.status !== 204 - 跨域请求时，如果后端没配
Access-Control-Allow-Origin，浏览器直接拦截，控制台报CORS错误，fetch甚至不会发出请求
用 axios 替代 fetch？注意默认行为差异
如果你用 axios，它默认序列化 data 并加 Content-Type，比 fetch 少些样板代码，但默认不带凭据（cookie/token）。
常见疏漏：
- 发送 cookie 需显式设置
withCredentials: true（且后端必须允许） -
axios.put(url, data)默认发PUT，但有些老后端只认POST+_method=PUT模拟，得手动配置 - 全局拦截器里修改
config.headers时，别覆盖已有的Authorization
例如添加 token：
axios.defaults.headers.common['Authorization'] = 'Bearer ' + token;
真正麻烦的从来不是“怎么发请求”，而是后端对 REST 的理解是否一致——比如把 PATCH 当 PUT 用，或要求所有创建接口都走 POST /api/v1/action/createUser。这时候，文档比规范更管用。
