こんにちは。
昨日は Automation and Programmability の全体概要を整理しましたが、本日はそこからもう少し踏み込んで、REST API / HTTP verbs / CRUD / JSON について学習しました。
前回は初見のワードがかなり多く、正直かなりぼんやりした印象だったのですが、今回はそれぞれの言葉が少しずつつながってきて、ようやく輪郭が見え始めた感覚があります。
とはいえ、まだ完全に理解できたというよりは、「何が何の役割なのか」が見えてきた段階です。今回も GenSpark に2枚のスライドへ整理してもらい、それを見ながらブログ記事として知識を落とし込んでいます。抽象的な分野ではありますが、文系出身の自分にはこうした“少しずつ輪郭が見えてくる感覚”がちょうど合っているように思います。
REST API とは何か
REST API は、Web の通信方式を使って、機器やコントローラをプログラムから操作する方法です。
今回の学習では、この REST API をレストランの注文にたとえる説明がとても分かりやすく感じました。
API が注文カウンター、クライアントが注文する人、サーバや機器やコントローラが厨房、そして HTTP method が「どんな注文を出すか」の種類です。難しい言葉に見えても、まずは「プログラムがお願いを出す窓口」と考えると入りやすいです。
HTTP verbs とは何か
HTTP verbs は、REST API で何をしたいかを表す動詞です。
今回押さえた主なものは、GET / POST / PUT / PATCH / DELETE の5つです。
GET は取得、POST は新規作成、PUT は既存内容の更新や置き換え、PATCH は一部だけ更新、DELETE は削除、という整理になります。
特に PUT と PATCH は似て見えますが、PUT は全体を置き換えるイメージ、PATCH は一部分だけ直すイメージです。
CRUD とは何か
CRUD は、データ操作の基本となる4つの動作の頭文字です。
Create（作成） / Read（読み取り） / Update（更新） / Delete（削除） をまとめた言葉で、API の世界ではとてもよく出てくるようです。
そして REST API では、この CRUD を HTTP verbs で表現していきます。
たとえば GET → Read、POST → Create、PUT / PATCH → Update、DELETE → Delete のように対応づけて考えます。
つまり CRUD は「操作の分類」、HTTP verbs は「その操作を伝えるための動詞」と整理すると、役割の違いがかなり見えやすくなりました。
JSON とは何か
JSON は、設定や情報を、プログラムが読みやすい形で表したデータ形式です。
たとえば設定情報や機器情報を、人が長い文章で読むのではなく、プログラムが扱いやすい形で並べて渡すために JSON が使われます。
今回の内容では、「REST API が会話の仕組みなら、JSON はその会話内容の書き方」と整理されていて、とても納得感がありました。
JSON の基本部品
JSON の基本部品として、まず覚えたいのが { }、[ ]、キー、値 です。
中かっこの { } は、ひとかたまりの オブジェクト を表します。
そしてその中では、キー が項目名、値 がその中身になります。
一方、角かっこの [ ] は、複数のデータを並べる 配列 を表します。
最初は記号が多く見えて少し身構えてしまいますが、「項目名と中身をセットで書く」「複数あるときは並べる」という感覚で見ると、少し読みやすくなってきました。
HTTP headers と authentication をやさしく見る
API のやり取りでは、本文そのものだけでなく、ヘッダ も大事な情報になります。
今回の学習では、代表例として Content-Type、Accept、Authorization を見ました。 キャプチャ2
Content-Type は、「これから送るデータはどんな形式ですか」を伝えるためのものです。
MDN でも、POST や PUT のようなリクエストで、クライアントは Content-Type を使ってサーバへ送信内容の種類を伝えると説明されています。REST API では application/json がよく使われます。
Accept は、「どんな形式で受け取りたいか」を示すためのものです。
たとえば API で JSON を受け取りたいときは Accept: application/json のように指定します。これは、クライアントが受け取れるデータ形式をサーバへ伝える役割です。
そして Authorization は、認証情報を送るためのヘッダです。
MDN では、Authorization ヘッダは保護されたリソースへアクセスするための資格情報を提供するために使われると説明されています。
つまり API にも「本人確認」があり、誰でも自由に操作できるわけではない、という点を押さえておくことが大切だと感じました。
REST API と JSON の関係
今回いちばん整理できたのは、REST API と JSON は同じものではない という点です。
最初は全部ひとまとめに見えてしまいますが、役割を分けるとかなり理解しやすくなります。
今回の学習内容に沿って言い換えると、
REST API はお願いを出す窓口、
HTTP verbs はどんな操作をしたいかを表す動詞、
CRUD は操作の分類、
JSON はやり取りするデータの書式です。
この整理ができるだけでも、Automation and Programmability の入口としてはかなり大きいと感じました。
今回の学習で感じたこと
昨日は初見のワードがかなり多くて、全体が少し霧の中にあるような感覚でしたが、今日はその霧の向こうにあった形が少し見えてきた気がします。
まだ細かい仕組みまで説明できる段階ではありませんが、「REST API は窓口」「HTTP verbs は動詞」「CRUD は操作分類」「JSON は書式」と分けて考えることで、だいぶ整理しやすくなりました。
この分野は、VLAN や ACL のようにその場で設定結果が見えやすい内容とは違って、概念同士のつながりを理解するまで少し時間がかかる印象です。
ただ、そのぶん一度つながりが見えてくると、急に理解しやすくなる感じもあります。今回の学習は、まさにその最初の一歩だったように思います。
まとめ
今回は Automation and Programmability 基礎（第2回） として、REST API / HTTP verbs / CRUD / JSON の関係を整理しました。
REST API は、Web の通信方式を使って機器やコントローラをプログラムから操作するための仕組みです。
その中で HTTP verbs は操作の動詞、CRUD は操作の分類、JSON はデータの書式として使われます。
さらに、Content-Type・Accept・Authorization といったヘッダを見ることで、「何を送るのか」「何を受け取りたいのか」「本人確認はどうするのか」まで含めて、API のやり取りを少し具体的にイメージできるようになりました。
まだ抽象的で難しさはありますが、昨日よりは確実に輪郭が見えてきました。
今後も少しずつ繰り返しながら、この分野に慣れていきたいと思います。
コメント