REST API

REST API は、アプリケーションのデータを /orders や /orders/42 のようなリソースとして公開し、クライアントが標準の HTTP メソッドでそれらを操作できるようにするものです。REST（Representational State Transfer）は標準規格ではなくアーキテクチャスタイルなので、実際の API がどこまで REST に従っているかはさまざまです。中心となる考え方は、リソース指向の URL、HTTP メソッドとステータスコードの意味に沿った使い方、そしてステートレスなリクエストです。つまり、各リクエストは認証情報を含め、サーバーが必要とするすべてを自身で運びます。

例

リクエスト	意味	一般的な成功時のレスポンス
GET /orders?status=open	未処理の注文を一覧取得	200 OK
GET /orders/42	1 件の注文を取得	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 は冪等であること。
• オブジェクトレベルの認可: ユーザー A が、ユーザー B の /orders/{id} を読めてはいけません。
• ページネーション、フィルタリング、ソート: 空のページや最終ページも含めて確認します。

ほかの API スタイルとの違い

GraphQL は通常、クライアントが必要なデータを記述する単一のエンドポイントを公開し、クエリの一部が失敗しても 200 を返すことが多いため、テストでは errors フィールドを確認する必要があります。SOAP は XML のエンベロープと形式的な WSDL 契約を使います。gRPC は HTTP/2 と Protocol Buffers を使います。REST のテストスイートは HTTP そのものに大きく依存しており、だからこそ API テスターにとって HTTP の基礎が非常に重要なのです。