REST Assured 请求失败的常见原因及正确配置方法-java教程-PHP中文网

REST Assured 请求失败的常见原因及正确配置方法

本文详解 REST Assured 中因误用 param()、错误设置 Content-Type 或缺失请求体导致 400/403 错误的问题，并提供符合 Postman 行为的标准化 JSON POST 写法。

本文详解 rest assured 中因误用 `param()`、错误设置 content-type 或缺失请求体导致 400/403 错误的问题，并提供符合 postman 行为的标准化 json post 写法。

在使用 REST Assured 测试 Micronaut（或其他 Spring Boot、Quarkus 等）REST API 时，一个典型误区是将 JSON 请求体误当作查询参数处理——这正是导致状态码异常（如 400 Bad Request 或 403 Forbidden）的根本原因之一。

? 核心问题定位

你最初的代码：

.param("name", "Test Device")

调用的是 param() 方法，它仅用于添加 URL 查询参数（query parameters） 或配合 @PathParam 的路径占位符，不会序列化为请求体（request body）。而你的 Postman 请求实际发送的是 JSON 格式的请求体（{"name":"Test Device"}），服务端自然无法从空 body 中解析出设备名称，从而返回 400；若服务端进一步校验了 Content-Type 或认证头完整性，也可能降级为 403。

此外，ContentType.JSON 在 REST Assured 中默认值为 "application/json; charset=utf-8"，部分严格校验 Content-Type 的框架（如 Micronaut 默认配置）可能拒绝带 charset 子句的头，或与 Postman 发送的纯 "application/json" 不完全匹配，造成解析失败。

✅ 正确写法：三要素齐全

一个能准确复现 Postman 行为的 REST Assured 请求必须满足以下三点：

✅ 使用 .body(...) 显式设置 JSON 请求体（非 .param()）
✅ 使用 .contentType("application/json")（不带 charset，与 Postman cURL 一致）
✅ 正确设置 Authorization: Bearer <token></token> 头

标准实现如下：

@Test
public void devicePostTest(RequestSpecification spec) {
    String jsonBody = "{\"name\":\"Test Device\"}";

    spec.given()
        .header("Authorization", "Bearer " + bearerToken)
        .contentType("application/json") // 注意：不是 ContentType.JSON
        .body(jsonBody)
        .when()
            .post("/user/38/devices")
        .then()
            .statusCode(201);
}

? 进阶建议：为提升可读性与可维护性，推荐使用 Jackson 或 Gson 序列化 Java 对象：

Device device = new Device("Test Device");
spec.given()
    .header("Authorization", "Bearer " + bearerToken)
    .contentType("application/json")
    .body(device) // REST Assured 自动调用 ObjectMapper 序列化（需 classpath 有 jackson-databind）
    .when().post("/user/38/devices")
    .then().statusCode(201);

⚠️ 注意事项与调试技巧

不要混用 param() 和 body()：param() 仅影响 URL（如 /user/38/devices?name=...），与 RESTful 资源创建语义相悖，且多数后端控制器不会从此处读取实体字段。
避免硬编码 JSON 字符串：易出错（引号转义、格式错误），优先使用对象序列化。
验证 token 有效性：403 有时并非头配置问题，而是 bearerToken 过期或权限不足，可通过 System.out.println(bearerToken) 简单确认。

开启 REST Assured 日志：快速比对与 Postman 差异：

spec.given().log().all() // 打印完整请求（含 headers + body）
    .and().body(jsonBody)
    .when().post("/user/38/devices")
    .then().log().status().statusCode(201);

遵循以上规范，即可确保 REST Assured 请求与 Postman 行为完全一致，顺利通过 201 创建断言，为后续集成测试打下坚实基础。