はじめに 👋
この記事は、個人的な学習の記録です。
主に得た知識一覧
💁♂️(この本を読むメリット一覧)
✅REST とは、何か?
✅COOL URI について
✅HTTP メソッドが8種類である意味
✅知らずに使っていた、UTF-8 の正体
✅ステータスコードの意味やその成り立ち - 「Im a teapot」
✅HTTP ヘッダとはそもそも何か
✅JSON とは、何か
✅RESTful なリソース設計について
まとめ 🍵
まずは、Web の歴史を教えてくれる 🐳
19970 年 11 月 12 日に Tim Berners-Lee
によってハイパーメディアを用いた分散型情報システムとして、WEB は誕生した。
その後、紆余曲折あり、SOAP VS REST の戦いの歴史が始まり
そのシンプルな作りから REST が勝利して、今日に至るとのことでこの本では、終始語られているが REST という考え方があったからこそ、ここまでネットは繁栄できたと言っても過言ではないらしい
次に、REST とは何か ❓ を知ることができる
略さずに言うと、REST(Representational State Transfer)で、本来は下記6つのアーキテクチャスタイルを組み合わせたアーキテクチャスタイルであるULCODC$SSとのことだったが
Fielding という人が、長いから REST にしましょうと命名したらしい 🤔
(統一/階層化/コードオンデマンド/クライアント/キャッシュ/ステートレスサーバ)
U = Uniform Interface
L = Layered System
C$ = Cacheable(“$”は“cache”の合図っぽい)
COD = Code on Demand(任意)
CS = Client–Server
S = Stateless
🌊🌊🌊🌊🌊🌊🌊🌊🌊🌊🌊🌊🌊🌊🌊🌊🌊🌊🌊🌊🌊🌊🌊🌊🌊🌊🌊🌊🌊🌊🌊🌊🌊🌊🌊🌊🌊🌊🌊
"Web の歴史と REST が如何に良いかを知った後は、REST の深掘りが始まる"
🌊🌊🌊🌊🌊🌊🌊🌊🌊🌊🌊🌊🌊🌊🌊🌊🌊🌊🌊🌊🌊🌊🌊🌊🌊🌊🌊🌊🌊🌊🌊🌊🌊🌊🌊🌊🌊🌊🌊
以下、今回読んで良かったと思えた内容一覧
COOL な URI とは何か ❓ 🏖️
COOLURI とは、変わらない URI こそ COOL な URI だということらしく、この概念は、ブックマークしたリソースがある日突然リンク切れになってたりすることが多かった時代に提唱された概念らしい。
特に、「URI と HTTP は、名詞と動詞のような関係性、故に URI は、名刺的な役割に徹する設計が好ましい」だったりと様々な、URI の設計上の教訓が P57 にて紹介されている。
例えば、この URI https://ja.wikipedia.org/wiki/あ
なのだが、実際 URI の仕様上許されてはいない文字が含まれている。
しかし、UTF-8 のお陰でその許されていない文字である「あ」を URI で表示させることができているというのを知った時は、興奮した。
この URI の表示がどのように、成立しているのかの解説として、UTF-8 のルールに従って「あ」を表現すると、 E3, 81, 82 らしく、URI の仕様上許容されていない文字は、%でエンコードする必要がとのことで結果以下がデコードした本来の URI になるらしい
https://ja.wikipedia.org/wiki/%E3%81%82
これにより、分かり易いリソースの名を、ひいては分かりやすい URI を提供し、ユーザーによって使い勝手の良いサービスへつながっているのかと思うと様々な技術や先人の知恵に支えられ Web というものが存在しているのだなと感動すら覚えた。
HTTP メソッド/HTTP ステータスコード/HTTP ヘッダについて 👬
🔹HTTP メソッド
特に、P108 の PUT がべき等でなくなる理由などは、勉強になったと感じる。
その他にも、POST の誤用に関して、GET、PUT、DELETE でできることを POST でやってしまおうとすることだとも書いてあり、それぞれのメソッドの使い分け方を根拠を持って理解することができるようになったと思う。
本書で紹介されている HTTP メソッドは、以下
| メソッド | 意味・用途 |
|---|---|
| GET | リソースの取得 |
| POST | 子リソースの作成、リソースへのデータの追加、その他の処理 |
| PUT | リソースの更新、リソースの作成 |
| HEAD | リソースのヘッダ(メタデータ)の取得 |
| OPTIONS | リソースがサポートしているメソッドの取得 |
| DELETE | リソースを削除する。 |
| TRACE | 自分宛にリクエストメッセージを返す(ループバック)試験 |
| CONECT | プロキシ動作のトンネル接続への変更 |
だが、TARACE、CONECT は、現在ではほとんど使われていない。
♦️ ステータスコード
次に、P112 ステータスコードについてだが基礎中の基礎かもしれないが、下記のように先頭の数字が何かで大体のエラー内容が把握できるという情報も有益だった。あと、未知のエラーなどは、その先頭の数字に 0x2 のステータスコードで表現されるというのもまだ出会したことはないが、知っていることで実際に、出会したとき冷静に対処できるなとも感じたので良かったと思う。
1xx ←処理継続中
2xx ←処理成功
3xx ←リダイレクト系
4xx ←クライアント側のエラー
5xx ←サーバー側のエラー
🔹HTTP ヘッダについて
このヘッダについて、知って良かったと思った箇所は、特にコンテントネゴシエーションとかいう機能が HTTP にはあって日本語の os を使っているユーザーには日本語を、英語の os を使ってたら英語を表示するというのができるとかいうところだ。メタデータというのは、使いこなせればかなり便利なのかもしれないと興味のきっかけとなったのでまた今度深ぼってみようと思う。
JSON について(P233) 📩
javaScript object notation の略で、その名の通り javaScript の記法を使用しているよくデータの送受信で使われているものだが、改めて JSON とは何かを理解する上でも良い機会となった。
特出すべき内容は、特にないが、例えば、JSON に用意されているデータ型は、以下の通りで
オブジェクト、配列、文字、数値、ブーリアン、null
とにかくシンプルだというのがわかる。そのシンプルさは、様々なプログラミング言語で用いられてる理由でもあるとの解説があり、終始本書ではシンプル is ベストな精神が伺える。
その他にも ❓
実例を用いた WEB サービスの設計例 🏣
郵便番号検索サービスの設計を用いて、Restful なリソース設計の例を教えてくれる。
特に、P248 あたりのリ「ソースに URI で名前を付ける」というところは、学びになった。
加えて、P250 などの「地域リソース」のところもかなりわかりやすかった。
要は、WEB API と WEB サービスを分けて設計してはいけないということとリソースの設計次第でそのサービスの使いやすさに大きく関わるってくるという話だと理解した。しかし、正直あまりここの章は、理解しきれていない......😅
感想 🌤️
実際には、用語などで知らない単語が多く読み進めるのにかなり時間がかかった割には、あまり知識がアップデートされた感覚はないが、WEB に関する根本的な情報を改めてなぜそうなっているのかも含めてぼんやりとではあるが理解できたのは良かったと思う。
また、別の知識を学習していく中で、再度この本に立ち帰り読んでみるとより解像度高く、この本を理解できるとも感じられたのは良かった。
次は、今回得た WEB の歴史的な背景知識と REST の知識を踏まえた上で通信系やサーバ関連の技術書を読んでみようと思う。
情報の豆粒 ☕️
🫘 P113「418 Im a teapot」ジョークステータスの存在
🫘「UNIX 時間は、1970 年 1 月 1 日 0 時 0 分 0 秒」
🫘P138HTTPS は、HTTP と SSL/TLS を組み合わせた通信の総称とのこと
🫘Firefox の live httpheaders という拡張機能でヘッダを簡単に見られるらしい
🫘CGI は、computer gateway interface の略
🫘 基本 4xx 系のステータスでみちの 4 系が返ってきた場合、400 で処理するとのこと
🫘P174 のよく聞く、セマンティックについて書かれている、セマンティックスは、翻訳すると「意味論」
🫘 UTF-8 とは?
文字を「数字の並び(バイト列)」に変換するルールのひとつ。
世界中の文字(ひらがな、漢字、アルファベット、絵文字…)を、コンピュータが扱える「0 と 1」に落とし込むための方式
🫘P174 から P230 は、Atom 関連の内容が多くあまり読む価値はなかった。
🫘URI のスキーム一覧