変更要約: 初版
6.3REST APIとデータ形式
コントローラや機器を自動化から操作する土台となるREST APIの性質（ステートレス・HTTP上で動く）、CRUD操作とHTTPメソッド（POST/GET/PUT/DELETE）の対応、成否を示すHTTPステータスコード（200/201/4xx/5xx）、そしてデータ交換の主役JSON（{}オブジェクト・[]配列・キーと値・データ型）の読み取りを、実務の観点から学びます。
前の節のコントローラを「スクリプトから操作する」その入口がREST APIです。REST APIは私たちが普段ブラウザで使っているHTTPの仕組みをそのまま流用し、機器の状態を「取得（GET）」「作成（POST）」「更新（PUT）」「削除（DELETE）」します。そしてやり取りされるデータの大半はJSONという軽量な形式です。この節では、REST APIの基本的な作法と、返ってきたJSONを正しく読み取る力を、CLIの代わりにAPIで運用する実務の視点から身につけます。
6.3.1REST APIの性質とCRUD/HTTPメソッド
- REST API＝HTTP上でリソース（機器・設定・状態）をURLで指し示し、HTTPメソッドで操作するAPIスタイル。ステートレス＝サーバはリクエスト間でクライアントのセッション状態を保持せず、各リクエストが自己完結して必要情報（認証トークン等）を都度含む。
- CRUD（Create/Read/Update/Delete）はHTTPメソッドに対応する＝作成=POST／取得=GET／更新=PUT（部分更新はPATCH）／削除=DELETE。例：
GET /api/v1/interfacesは全インタフェースの状態取得、POST /api/v1/vlansは新規VLAN作成。 - リクエストにはヘッダ（
Content-Type: application/json・認証トークン等）と、作成/更新時はボディ（JSON等のペイロード）を付ける。GETは通常ボディを持たずURLで対象を指定する。
6.3.2HTTPステータスコードで成否を読む
- 2xx＝成功：
200 OK（取得/更新成功）、201 Created（新規作成成功）。自動化スクリプトはこのコードで処理継続を判断する。 - 4xx＝クライアント側の誤り：
400 Bad Request（リクエストの形式不正）、401 Unauthorized（未認証）、403 Forbidden（権限不足）、404 Not Found（対象なし）。依頼側の直しどころを示す。 - 5xx＝サーバ側の誤り：
500 Internal Server Error等。リクエストは妥当でもサーバ内部で失敗した状態で、依頼側の修正では直らない。4xxか5xxかで切り分け先（自分の依頼 vs サーバ）が変わる。
「CRUD⇔HTTPメソッド（作成POST/取得GET/更新PUT/削除DELETE）」「RESTはステートレス」「2xx成功・4xxクライアント誤り・5xxサーバ誤り」が最頻出です。特に401（未認証）と403（権限不足）、400（形式不正）と404（対象なし）の意味の違いを取り違えないようにしましょう。
6.3.3JSONの読み取り（オブジェクト・配列・データ型）
- JSON＝
キー:値のペアを{ }で囲ったオブジェクトで表す軽量データ形式。値には文字列（"up"）・数値（1500・引用符なし）・真偽値（true/false）・null・入れ子のオブジェクト・配列を取れる。 - 配列＝
[ ]で囲った順序付きの並び。例"addresses": ["10.0.0.1", "10.0.0.2"]は2要素の文字列配列。要素は0番目から数える（addresses[0]は"10.0.0.1"）。 - データ型の見分けが実務で効く＝
"enabled": trueは真偽値だが"enabled": "true"は文字列で、スクリプトが型を取り違えると条件判定を誤る。"mtu": 1500は数値、"mtu": "1500"は文字列。
あなたは監視スクリプトを書いていて、コントローラの GET /api/v1/interfaces/GigabitEthernet0/1 に対し次のJSONが返ってきたとします——{ "name": "GigabitEthernet0/1", "enabled": true, "mtu": 1500, "addresses": ["10.0.0.1", "10.0.0.2"], "description": null }。まずステータスコードが 200 OK であることを確認して初めてボディの解釈へ進みます（401 なら認証トークンの問題、404 ならそのインタフェース名が存在しない、と切り分けが変わるためです）。ボディは1つのオブジェクト（{ }）で、enabled の値は引用符のない true なので真偽値——ここで "true"（引用符付き＝文字列）と取り違えると、if enabled true の判定が常に偽になるバグを生みます。mtu は 1500 で引用符がないため数値として計算に使えます。addresses は [ ] の配列で、addresses[0] が "10.0.0.1"、addresses[1] が "10.0.0.2"（0番目から数える点に注意）。description は null で「値が未設定」を意味し、空文字列 "" とは区別されます。もしこのインタフェースを無効化したいなら、取得（GET）ではなく更新（PUT）で { "enabled": false } を送るのが正しく、削除（DELETE）はインタフェース設定そのものを消す別の操作です。このようにステータスで成否を切り分け → JSONの型と構造を正確に読む → 目的に合ったメソッドで操作するという一連の作法が、CLIをAPIに置き換える運用の基礎になります。
| CRUD操作 | HTTPメソッド | 例 | 成功時の主なコード |
|---|---|---|---|
| Create（作成） | POST | POST /api/v1/vlans | 201 Created |
| Read（取得） | GET | GET /api/v1/interfaces | 200 OK |
| Update（更新） | PUT（部分はPATCH） | PUT /api/v1/interfaces/Gi0/1 | 200 OK |
| Delete（削除） | DELETE | DELETE /api/v1/vlans/50 | 200 / 204 |
ひっかけ： JSONの "enabled": "true" を真偽値と読むのは誤りです——引用符で囲まれているため文字列であり、真偽値の true（引用符なし）とは型が異なります。また「RESTはステートフルでサーバがセッションを保持する」も誤り＝RESTはステートレスで、各リクエストが認証情報等を自己完結して含みます。401（未認証）と403（認証済みだが権限不足）も混同しないようにしましょう。
6.3.4この節のまとめ
- REST APIはステートレスなHTTPベースで、CRUDを作成POST/取得GET/更新PUT/削除DELETEに対応させる
- HTTPステータスは2xx成功・4xxクライアント誤り・5xxサーバ誤り。401(未認証)と403(権限不足)、400(形式不正)と404(対象なし)を区別する
- JSONは
{}オブジェクトと[]配列で構成し、文字列/数値/真偽値/nullの型を正確に読む（trueと"true"は別物・配列は0番目から）
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 自動化スクリプトからコントローラのREST APIを呼び、既存のインタフェースGi0/1の設定を「有効から無効」へ変更したい。用いるHTTPメソッドとして最も適切なものはどれか。
Q2. REST API呼び出しの結果、レスポンスとして `401 Unauthorized` が返ってきた。自動化スクリプトが次に確認・対処すべき事項として最も適切なものはどれか。
Q3. REST APIから次のJSONが返った：`{ "enabled": true, "mtu": 1500, "addresses": ["10.0.0.1", "10.0.0.2"] }`。この内容の解釈として最も適切なものはどれか。