REST API

REST API는 애플리케이션의 데이터를 /orders나 /orders/42 같은 리소스로 노출하고, 클라이언트가 표준 HTTP 메서드로 이를 조작하게 합니다. REST(Representational State Transfer)는 표준이 아니라 아키텍처 스타일이므로, 실제 API가 이를 따르는 정도는 제각각입니다. 핵심 개념은 리소스 중심의 URL, HTTP 메서드와 상태 코드의 의미 있는 사용, 그리고 무상태(stateless) 요청입니다. 즉 각 요청은 인증 정보를 포함해 서버에 필요한 모든 것을 담고 있어야 합니다.

예시

요청	의미	일반적인 성공 응답
GET /orders?status=open	미처리 주문 목록 조회	200 OK
GET /orders/42	주문 한 건 조회	200 OK
POST /orders	주문 생성	201 Created + Location 헤더
PUT /orders/42	주문 전체 교체	200 OK 또는 204 No Content
PATCH /orders/42	일부 필드 변경	200 OK
DELETE /orders/42	주문 삭제	204 No Content

REST Assured 5로 작성한 테스트:

import static io.restassured.RestAssured.given;
import static org.hamcrest.Matchers.equalTo;

given()
    .baseUri("https://api.example.com")
    .header("Accept", "application/json")
.when()
    .get("/orders/42")
.then()
    .statusCode(200)
    .body("id", equalTo(42))
    .body("status", equalTo("open"));

REST API에서 무엇을 테스트해야 하는가

• 상태 코드: 성공 경로와 모든 실패 경로(인증 누락, 잘못된 역할, 유효하지 않은 본문, 존재하지 않는 id, 충돌)를 확인합니다.
• 응답 본문과 스키마: 필드 이름, 타입, 필수 필드를 확인하고, 민감한 필드가 노출되지 않는지 확인합니다.
• 헤더: Content-Type, 생성 후의 Location, 필요한 경우 캐싱 및 CORS 헤더를 확인합니다.
• 메서드 의미론: GET은 부수 효과가 없어야 하고, PUT과 DELETE는 멱등(idempotent)이어야 합니다.
• 객체 수준 인가(authorization): 사용자 A가 사용자 B의 /orders/{id}를 읽을 수 없어야 합니다.
• 페이지네이션, 필터링, 정렬: 빈 페이지와 마지막 페이지까지 포함해 확인합니다.

다른 API 스타일과의 차이

GraphQL은 보통 단일 엔드포인트를 노출하고 클라이언트가 원하는 데이터를 기술하는 방식이며, 쿼리 일부가 실패해도 200을 반환하는 경우가 많으므로 테스트에서 errors 필드를 반드시 확인해야 합니다. SOAP은 XML 엔벨로프와 공식 WSDL 계약을 사용합니다. gRPC는 HTTP/2와 Protocol Buffers를 사용합니다. REST 테스트 스위트는 HTTP 자체에 크게 의존하므로, API 테스터에게 HTTP 기초가 그만큼 중요합니다.