HTTP API をシミュレートする

フォルダーを右クリック ▸ 追加 ▸ HTTP サーバー。

設定する

サーバーはリクエストとまったく同じ項目で設定します。そこがポイントです。 メソッド と パス が待ち受けるルートを決め、 ステータス、ヘッダー、ボディ が返されるレスポンスを決めます。

項目	役割
メソッド	ルートのメソッド
アドレス	localhost:<ポート><パス> — ホストは固定です
モックステータス	返されるコード。既定は 200
ヘッダー	レスポンスのヘッダー
ボディ	レスポンスのボディ

ルーティング

ルートは メソッド + パス の組です。照合は パスの完全一致 で行われ、 クエリ文字列は無視されます。 どのルートにも一致しないままポートに届いた呼び出しには 404 が返ります。

2 つのルートが衝突するのは、メソッド、パス、そして ポートがすべて同じときだけです。 したがって、ルートごとにサーバーリクエストを作成し、まとめて開始できます。

GET  localhost:8080/clients      → 200、顧客の一覧
GET  localhost:8080/clients/42   → 200、顧客 1 件
POST localhost:8080/clients      → 201、Location ヘッダー付き
GET  localhost:8080/clients/999  → 404（一致するルートなし: 既定のレスポンス）

テンプレート

ヘッダーとボディは 着信ごとに 解決されます。 そのため、{{maintenant}} や {{compteur}} を含むボディは、 変数が変われば呼び出しごとに変化します。

ヒント：これを使えば、サーバーを動かしたまま挙動を操れます。 環境変数の値を変えるだけで、次の呼び出しには別のレスポンスが返り、 再起動は不要です。

ポートの共有

シミュレーション用の HTTP サーバーと WebSocket または Socket.IO サーバーは 同じポートで待ち受けられます。 Restorm は通常のリクエストを HTTP のルートへ、 アップグレード要求をリアルタイム系のサーバーへ振り分けます。

シナリオの中で

HTTP サーバー アクションはシナリオの実行中だけルートをホストし、 受信した呼び出しごとに { request, response } を持つ served イベントを発行します。 webhook をテストする手段になります。

HTTP サーバー ──connected──► HTTP リクエスト「webhook を発火させる」
     └─────────served──────► request.body に対してアサート
                              その後 ──► HTTP サーバーを閉じる

ホストされるサーバー を参照してください。