How to Test REST APIs in Your Browser — A Developer's Guide

Learn how to test REST APIs in your browser, when CORS blocks direct requests, and when to switch to proxy-based testing. Covers HTTP methods, headers, auth, status codes, and hands-on examples.

JSONTech 团队March 25, 202610 min read

什么是 API 测试？

当今的 Web 与移动应用几乎都建立在 API 之上。当你刷新 Twitter 时间线、在亚马逊下单，或在手机上查看天气时，背后都有 API 调用在发生。API 测试是指向这些端点发送请求，并验证响应是否正确——包括正确的状态码、预期的数据结构，以及可接受的性能表现。

与 UI 测试不同，API 测试针对的是界面之下的那一层。它能更早发现问题、执行更快，还能覆盖许多难以通过浏览器点击触发的场景。无论你是在自建 API，还是对接第三方服务，快速验证端点都是开发者的一项基本功。

HTTP 方法说明

REST API 使用标准 HTTP 方法表示要对资源执行的操作。下面是速查表：

方法	用途	是否有请求体
`GET`	获取单个资源或资源集合	否
`POST`	创建新资源	是
`PUT`	完整替换某一资源	是
`PATCH`	部分更新资源	是
`DELETE`	删除资源	通常没有

关键区别： PUT 会替换整个资源——未出现在请求里的字段可能被清空。PATCH 只更新请求体中出现的字段。多数支持更新的 API 会用 PATCH 做局部修改，用 PUT 做整体替换。

如何在浏览器中测试 API

你不必安装 Postman，也不必背下一堆 cURL 参数才能测试 API。JSONTech.net 上的 API Explorer 可以在浏览器模式下测试已开放 CORS 的 API，也可以在浏览器拦截请求时切换到代理模式。步骤如下：

打开 API Explorer 工具。
在下拉菜单中选择 HTTP 方法（GET、POST、PUT、PATCH 或 DELETE）。
填写端点 URL。例如：https://jsonplaceholder.typicode.com/posts/1
按需添加请求头（例如 Content-Type 或 Authorization）。
若该方法需要请求体（POST、PUT、PATCH），在正文编辑器中输入 JSON。
点击 Send，查看响应——状态码、响应头以及格式化后的 JSON 正文。

如果浏览器提示 CORS 错误，可以把 API Explorer 切换到代理模式。这样真实请求会经过 JSONTech 的边缘基础设施转发，你无需离开当前页面就能继续调试。

示例：获取一篇文章

GET https://jsonplaceholder.typicode.com/posts/1

Response (200 OK):
{
  "userId": 1,
  "id": 1,
  "title": "sunt aut facere repellat provident occaecati excepturi optio reprehenderit",
  "body": "quia et suscipit\\nsuscipit recusandae consequuntur..."
}

示例：创建一篇文章

POST https://jsonplaceholder.typicode.com/posts
Content-Type: application/json

{
  "title": "My New Post",
  "body": "This is the content of my post.",
  "userId": 1
}

Response (201 Created):
{
  "id": 101,
  "title": "My New Post",
  "body": "This is the content of my post.",
  "userId": 1
}

理解请求头

请求头携带与请求相关的元数据，用来告诉服务器你期望的数据格式、你的身份，以及连接应如何行为。下面是最常用的几项：

请求头	作用	示例值
`Content-Type`	请求正文的格式	`application/json`
`Accept`	期望响应采用的格式	`application/json`
`Authorization`	身份认证凭据	`Bearer eyJhbGciOi...`
`Cache-Control`	缓存相关指令	`no-cache`
`User-Agent`	标识客户端应用	`MyApp/1.0`

在 POST/PUT 请求中忘记设置 Content-Type: application/json 是 API 返回 400 Bad Request 的常见原因之一。没有该头，服务器往往无法正确解析正文。

身份验证方式

大多数线上 API 都需要认证。下面三种模式最为常见：

Bearer Token（JWT）

现代 API 中最常见的做法：在 Authorization 请求头中附带令牌：

{
  "headers": {
    "Authorization": "Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c",
    "Content-Type": "application/json"
  }
}

基本认证（Basic Auth）

将用户名和密码编码为 Base64 字符串。实现简单，但仅在 HTTPS 下才足够安全：

{
  "headers": {
    "Authorization": "Basic dXNlcm5hbWU6cGFzc3dvcmQ=",
    "Content-Type": "application/json"
  }
}

API Key

部分 API 通过自定义请求头或查询参数传递固定密钥：

// As a header
{
  "headers": {
    "X-API-Key": "sk_live_abc123def456"
  }
}

// As a query parameter
GET https://api.example.com/data?api_key=sk_live_abc123def456

阅读 API 响应

发出请求后，响应会说明究竟发生了什么。需要关注三个方面：状态码、响应头和正文。

状态码

代码	含义	常见出现场景
`200`	OK	GET、PUT、PATCH 或 DELETE 成功
`201`	Created	POST 成功并创建了新资源
`400`	Bad Request	JSON 无效、缺少必填字段、类型错误等
`401`	Unauthorized	未提供或令牌已过期
`403`	Forbidden	凭据有效但权限不足
`404`	Not Found	端点或资源不存在
`500`	Internal Server Error	服务器端内部错误

响应头

请关注例如 Content-Type（确认响应格式）、X-RateLimit-Remaining（剩余可调用次数）以及 Retry-After（触发限流后何时可重试）等头字段。

JSON 正文

业务数据一般在响应正文中。设计良好的 API 往往会用统一的结构包装数据：

{
  "data": {
    "id": 42,
    "name": "Widget",
    "price": 9.99
  },
  "meta": {
    "request_id": "req_8f3a2b"
  }
}

出错时，返回的可能是错误对象而非数据对象。应先看状态码，再按情况解析正文。

CORS：是什么，以及为什么会报错

跨源资源共享（CORS）是浏览器的一项安全机制。当运行在 localhost:3000 上的 JavaScript 去请求 api.example.com 上的 API 时，除非目标服务器通过 CORS 响应头明确允许，否则浏览器会拦截该请求。

典型的报错信息如下：

Access to fetch at 'https://api.example.com/data' from origin
'http://localhost:3000' has been blocked by CORS policy: No
'Access-Control-Allow-Origin' header is present on the requested resource.

这通常不是你的业务代码有 bug，而是浏览器在执行安全策略；解决办法多半在服务器端。常见的变通方式包括：

联系 API 提供方，请对方把你的源加入其 Access-Control-Allow-Origin 配置。
使用代理：把请求先打到自己的后端（例如 Next.js API Route 或简单的 Express 服务），由同源后端转发，从而绕开浏览器的跨源限制。
使用带代理选项的浏览器工具，例如 API Explorer：开放 API 先用浏览器模式，遇到 CORS 拦截时再切换到由 JSONTech 代发请求的代理模式。

CORS 只约束浏览器环境。cURL、Postman 以及服务端代码不受 CORS 限制——它们并不运行在浏览器的沙箱里。

常见的 API 测试误区

从新手到需要对接陌生 API 的资深开发者，都容易踩下面这些坑：

忘记设置 Content-Type。 发送 JSON 正文却未带 Content-Type: application/json 时，很多服务器会拒绝请求或解析错误。
该用 POST 却用了 GET。 GET 不应携带请求体；若要提交数据，应使用 POST、PUT 或 PATCH。
只看正文不看状态码。 即使正文里写了错误信息，HTTP 仍是 200 也不代表成功；务必以实际状态码为准。
把凭据硬编码进 URL。 能用请求头时，不要把 API 密钥或令牌放在查询串里——URL 可能进入服务器日志、浏览器历史和 Referer。
只测「一切正常」的路径。 还应主动发送畸形 JSON、空正文、缺字段、无效令牌等，观察 API 的真实错误处理。
不关注速率限制。 超出配额时不少 API 会返回 429；应留意 X-RateLimit-Remaining 等头信息。
把 CORS 报错当成服务器故障。 CORS 报错表示浏览器拦截了响应；服务端有时其实已正常返回，只是前端拿不到结果。

动手试一试

想马上试一发？ 打开 API Explorer，对 https://jsonplaceholder.typicode.com/users/1 发送一条 GET 请求。无需离开浏览器，即可看到完整响应——状态码、响应头以及格式化后的 JSON 正文；如果其他 API 被 CORS 拦截，还可以切到代理模式重试。

无需下载、注册或复杂配置：选好方法、填入 URL，点击 Send 即可。