Mímisbrunnr知恵の泉

← コンピュータネットワーク 一覧

🎓 レベル：標準　|　重要度：A（必須） 📎 前提：HTTP/HTTPS

要点（BLUF）

RESTの考え方：URLとメソッド

RESTでは、操作したい対象（リソース）をURLで指し、何をするかをHTTPメソッドで表します。

操作（CRUD）HTTPメソッド例
Read（参照）GETGET /api/interfaces
Create（作成）POSTPOST /api/interfaces
Update（更新）PUT / PATCHPUT /api/interfaces/Gi0-1
Delete（削除）DELETEDELETE /api/interfaces/Gi0-1

レスポンスには[[05-02_HTTP_HTTPS]]のステータスコードが付きます（200成功・201作成・401認証要・404未検出など）。認証はトークンやAPIキーをヘッダに添えるのが一般的です。

graph LR
  S["スクリプト／アプリ"]
  C["コントローラ（REST API・HTTPS）"]
  S -->|"GET /api/devices （トークン付き）"| C
  C -->|"200 OK ＋ JSON本文"| S

JSON：データの運び方

JSONは「キーと値」「配列」「入れ子」で構造化データを表します。Python標準の json で解析できます（言語明示）。

import json

# コントローラが返す機器一覧を模したJSON
payload = '''
{
  "devices": [
    {"hostname": "R1", "mgmt_ip": "192.168.20.1", "role": "router", "up": true},
    {"hostname": "SW1", "mgmt_ip": "192.168.20.2", "role": "switch", "up": false}
  ],
  "count": 2
}
'''

data = json.loads(payload)            # JSON文字列 -> Pythonの辞書
print("count:", data["count"])
for d in data["devices"]:
    state = "up" if d["up"] else "down"
    print(f"{d['hostname']:4} {d['mgmt_ip']:14} {d['role']:7} {state}")

# 逆向き: Pythonの辞書 -> JSON文字列（POST本文を組み立てる）
new_if = {"name": "Gi0/1", "vlan": 10, "enabled": True}
print("body:", json.dumps(new_if))

実行結果：

count: 2
R1   192.168.20.1   router  up
SW1  192.168.20.2   switch  down

最後の json.dumps 行はこの後に続けて出力されます：

body: {"name": "Gi0/1", "vlan": 10, "enabled": true}

注目：JSONの true/false/null は、Pythonでは True/False/None に対応します。json.loads が文字列を辞書に、json.dumps が辞書を文字列に変換し、APIとPythonの世界を橋渡しします。

JSONの構文ルール

XMLやYAMLも使われますが、REST APIではJSONが事実上の標準です（YAMLは設定ファイル、XMLはNETCONFで多い）。

なぜRESTとJSONが標準なのか（設計の直観）

RESTは既存のHTTPの仕組み（URL・メソッド・ステータス）をそのまま流用するため、新しい通信規約を覚えずに済み、Webの道具（ブラウザ・curl・ライブラリ）がそのまま使えます。JSONは人が読めて機械が解析しやすいちょうど中間の表現で、どの言語にもパーサがあります。「既存の枯れた技術を組み合わせて、学習コストを最小化する」——これが自動化を一気に普及させた設計判断です。

⚠️ よくある誤解

対応 lab

関連