第5章 · インフラと自動化·v1.0.0·更新 2026/7/20·読了目安 約17分
変更要約: 初版
5.4応答とモデルの解釈
この節の要点
RESTCONF/NETCONFの応答（JSON/XML・<ok/>・rpc-reply）と、それらの土台となるYANGデータモデル（container/list/leafの階層）、そして変更差分を表すunified diff（@@ハンク・+/-行）を読み解き、「この応答は成功か失敗か」「このモデルのどこが何を表すか」「この差分は結局何を変えるか」を判断できるようにします。
モデル駆動の自動化では、機器とやり取りするのは人間向けのshow出力ではなく、構造化された応答（JSON/XML）とそれを規定するモデル（YANG）です。自動化が「うまくいったのか」を判断するには、応答の形から成否を読み、モデルのどこが何を表すかを掴み、変更差分が結局何を変えるかを読めなければなりません。この節では、暗記でなく提示された応答・モデル・差分の解釈として、この読解力を鍛えます。
5.4.1RESTCONF/NETCONF応答を読む
- RESTCONFはHTTP上でCRUDをHTTPメソッドに対応させる（GET=取得/POST=作成/PUT=置換/PATCH=部分更新/DELETE=削除）。応答はHTTPステータス＋JSON/XML bodyで、
200 OKや201 Createdは成功、204 No Contentは本文なしの成功、401は未認証、404はパス（データ）不在、409は競合。ステータスとbodyの両方で成否を読む。 - NETCONFはSSH(通常830番)上でXMLをやり取りし、成功は
<rpc-reply>内の<ok/>、失敗は<rpc-error>（<error-tag>に原因）で表す。設定はcandidate（編集用）→ commit → running（稼働中）のデータストア分離があり、<edit-config>後の<commit>で確定する。「応答が<ok/>か<rpc-error>か」で成否を判断する。 - JSON応答のキー名は名前空間付きで読む：例
"ietf-interfaces:interface": [{ "name": "GigabitEthernet2", "enabled": true }]は「ietf-interfacesモデルのinterfaceリストに、名前GigabitEthernet2・有効なエントリがある」と読める。どのモデルの・どの要素が・どんな値かを落ち着いて対応付ける。