理解Rest-Assured中的API请求与响应
在使用rest-assured进行api自动化测试时，我们经常会遇到不同http方法（如post、put）对应不同业务逻辑和端点的情况。post请求通常用于创建资源，而put请求则用于更新现有资源。每个请求都期望从服务器获得一个特定的响应，包括状态码、响应头和响应体。
在Rest-Assured中，我们通过链式调用来构建请求、发送请求并验证响应。例如，given().when().then()结构清晰地定义了请求的准备、执行和验证阶段。Hamcrest断言库常用于对响应体内容进行灵活且可读性强的验证。
错误场景分析：PUT请求的JSON解析异常
当执行PUT请求并尝试使用Hamcrest对响应体进行断言时，可能会遇到以下错误： java.lang.IllegalArgumentException: The JSON input text should neither be null nor empty. 这个异常表明Rest-Assured在尝试解析服务器返回的JSON响应体时，发现响应体为空或null。然而，日志中显示HTTP状态码为200 OK，这似乎与预期不符。
仔细查看PUT请求的响应日志，我们会发现关键信息：
HTTP/1.1 200 OK ... Content-Length: 0 ...
Content-Length: 0明确指出服务器返回的响应体是空的。尽管状态码是200（成功），但没有实际的JSON内容可供解析和断言。这就是导致IllegalArgumentException的根本原因。
根本原因：API端点配置不当
问题的核心在于PUT请求使用了错误的API端点。在许多RESTful API设计中，创建资源和更新资源通常会对应不同的URI路径。例如，一个用于添加（POST）资源的端点可能是/add，而更新（PUT）资源则可能对应/update。
在提供的示例中，POST请求用于添加位置，其端点为/maps/api/place/add/json。而PUT请求本意是更新位置，却错误地沿用了相同的端点/maps/api/place/add/json。服务器在收到对/add端点的PUT请求时，可能无法找到对应的处理逻辑，或者由于该端点仅支持POST方法，导致它返回一个空的响应体（尽管可能带有200 OK状态码，表示请求本身被接收，但没有可用的内容）。
解决方案：使用正确的API端点
解决此问题的关键是为PUT请求使用正确的API端点。根据API设计规范，更新位置的端点通常会包含“update”字样，例如： https://rahulshettyacademy.com/maps/api/place/update/json?key=qaclick123
将PUT请求的URL修改为正确的更新端点，服务器就能正确处理请求并返回包含预期消息（如"msg": "Address successfully updated"）的JSON响应体。
修正后的代码示例
以下是修正PUT请求端点后的完整Rest-Assured测试代码：
import io.restassured.RestAssured;
import io.restassured.path.json.JsonPath;
import static io.restassured.RestAssured.*;
import static org.hamcrest.Matchers.*;
public class Basics {
public static void main(String[] args) {
// 设置基础URI
RestAssured.baseURI = "https://rahulshettyacademy.com";
// 1. 添加位置 (POST请求)
String response = given().log().all().queryParam("key", "qaclick123")
.header("Content-Type","application/json")
// payLoad.addLocation() 假设是一个返回JSON字符串的方法
.body(payLoad.addLocation())
.when().post("/maps/api/place/add/json")
.then().assertThat().statusCode(200)
.body("scope", equalTo("APP"))
.header("Server",("Apache/2.4.41 (Ubuntu)"))
.extract().response().asString();
System.out.println("Add Location Response: " + response);
// 使用JsonPath解析响应，提取place_id
JsonPath js = new JsonPath(response);
String place_id = js.getString("place_id");
System.out.println("Extracted Place ID: " + place_id);
// 2. 更新位置 (PUT请求) - 使用正确的更新端点
given().log().all().queryParam("key","qaclick123")
.header("Content-Type","application/json")
.body("{\n" +
"\"place_id\":\""+place_id+"\",\n" +
"\"address\":\"70 Summer walk, USA\",\n" +
"\"key\":\"qaclick123\"\n" +
"}")
.when().put("/maps/api/place/update/json") // *** 修正后的端点 ***
.then().log().all().assertThat()
.statusCode(200).body("msg",equalTo("Address successfully updated"));
System.out.println("Location updated successfully.");
}
}
// 假设 payLoad 类及其 addLocation 方法如下
class payLoad {
public static String addLocation() {
return "{\n" +
" \"location\": {\n" +
" \"lat\": -38.383494,\n" +
" \"lng\": 33.427362\n" +
" },\n" +
"\"accuracy\": 50,\n" +
"\"name\": \"Frontline house\",\n" +
"\"phone_number\": \"(+91) 983 893 3937\",\n" +
"\"address\": \"29, side layout, cohen 09\",\n" +
"\"types\": [\n" +
" \"shoe park\",\n" +
" \"shop\"\n" +
"],\n" +
"\"website\": \"http://google.com\",\n" +
"\"language\": \"English-IN\"\n" +
"}";
}
}注意事项与最佳实践
- 查阅API文档： 在进行API测试之前，务必详细阅读API提供方提供的文档。文档会明确指出每个端点支持的HTTP方法、预期的请求体格式、响应结构以及任何特定参数要求。
- 区分HTTP方法和URI： 理解RESTful API的设计原则。POST通常用于创建资源，PUT用于完全替换或更新资源，PATCH用于部分更新，GET用于获取资源，DELETE用于删除资源。不同的操作通常对应不同的URI路径或至少是不同的HTTP方法与相同URI的组合。
- 充分利用Rest-Assured的日志功能： given().log().all()和then().log().all()是调试API请求和响应的强大工具。它们可以打印出完整的请求和响应信息，包括请求头、请求体、响应头、响应体和状态码，这对于识别问题（如空响应体、错误的请求头等）至关重要。
- 异常处理： 在实际项目中，应考虑对API请求可能抛出的各种异常进行处理，例如网络连接问题、响应超时或解析错误。
- 模块化请求体： 像示例中的payLoad.addLocation()一样，将请求体封装成单独的方法或对象，可以提高代码的可读性和可维护性，尤其当请求体复杂或需要在多个地方复用时。
- 响应体断言： 当预期响应体不为空时，才进行JSON或XML内容的断言。如果服务器返回Content-Length: 0，则应断言响应体为空，或者更进一步检查状态码是否符合预期（例如，204 No Content）。
总结
在Rest-Assured进行API自动化测试时，遇到IllegalArgumentException: The JSON input text should neither be null nor empty错误，尤其是在PUT请求中，往往是由于使用了不正确的API端点导致的。服务器接收到对错误端点的请求时，可能返回一个空的响应体，即使HTTP状态码显示成功。通过仔细核对API文档，确保为每个HTTP方法和操作使用正确的URI，并结合Rest-Assured强大的日志功能进行调试，可以有效避免此类问题，提升测试脚本的健壮性。
