エンジニアとして成長していくにあたって、RESTの考え方に習熟していきたいと思った時に、「そもそもWebとは」みたいなことへの知識もあると、より理解が深まるよと上司に紹介していただきました。
特に自分は学生時代もあまりPCに触れたことがなく知識がほぼ0であったため、何か新しいことが得られればと思い読んでみました。
構成
1章 Webとは何か
2章 Webの歴史
3章 REST Webのアーキテクチャスタイル 4章 URIの仕様
5章 URIの設計
6章 HTTPの基本
7章 HTTPメソッド
8章 ステータスコード
9章 HTTPヘッダ
10章 HTML
11章 microformats
12章 Atom
13章 Atom Publishing Protocol
14章 JSON
15章 読み取り専用のWebサービスの設計
16章 書き込み可能なWebサービスの設計
17章 リソースの設計
メモ
アーキテクチャスタイル
別名「（マクロ）アーキテクチャパターン」とも言い、複数のアーキテクチャに共通する性質、様式、作法あるいは流儀を指す言葉で、例えばMVCやパイプ&フィルタ、イベントシステムなどがある。
パターンという言葉からデザインパターンが想像されることもあるが、いわゆるデザインパターンは別名「マイクロアーキテクチャパターン」とも言い、アーキテクチャスタイルよりも粒度の小さいクラスなどの設計様式を指す。
REST
RESTは数あるアーキテクチャスタイルの中でも、特にネットワークシステムのアーキテクチャスタイルである。ネットワークシステムのアーキテクチャスタイルで最も有名なのはクライアント/サーバであり、そしてWebはクライアント/サーバでもある。（RESTはクライアント/サーバから派生したものでもある。）
RESTとはつまり以下6つを組み合わせたアーキテクチャスタイル
- クライアント/サーバ
- ユーザインタフェースと処理を分離する
- ステートレスサーバ
- サーバ側でアプリケーション状態を持たない
- キャッシュ
- クライアントとサーバの通信回数と量を減らす
- 統一インタフェース
- インタフェースを固定する
- 階層化システム
- システムを階層に分離する
- コードオンデマンド
- プログラムをクライアントにダウンロードして実行する
アドレス可能性
RESTfulなWebサービスの性質として最も重要なもの。
これは「URIさえあればリソースを一位に指し示すことができる」と言う性質であり、URIのこの性質がなければ接続性と統一インタフェースを実現できない。
接続性
リソースをリンクで接続することで1つのアプリケーションを構成するという考え方。
RESTの基幹をなす思想。
統一インタフェース
URIで指し示したリソースに対する操作を、統一した限定的なインタフェースで行うアーキテクチャスタイルのこと。
例えばHTTP1.1ではGEtやPOSTなど8個のメソッドだけが定義されており、通常はこれ以上増えない。
インタフェースの柔軟性に制限を加えることで全体のアーキテクチャがシンプルになり、またインタフェースを統一することでクライアントとサーバの実装の独立性が向上する。
URI
http:yohei:pass@blog.example.jp:8000/search?q=test&debug=true#n10
このURIは以下のように分けられる
- URIスキーム：http
- ユーザ情報：yohei:pass
- ホスト名：blog.example.com
- ポート番号：8000
- パス：/search
- クエリパラメータ：q=test&debug=true
- URIフラグメント：#n10
変わらないURIこそが最上のURI
1998年当時、URIが変更になることは日常茶飯事であった。
しかしながらこれはWebの根幹を揺るがす問題で、Webとはそれぞれのリソースに他のリソースへのリンクが埋め込まれたハイパーメディアシステムである中で、リンクが切れてしまうことはそれが機能しないことを意味するからだ。
URIを変わりにくくするためには
- プログラミング言語に依存した拡張子やパスを含めない
- 言語を変えたら使えなくなる
- メソッド名やセッションIDを含めない
- メソッド名が変わった瞬間、またログインし直すたびに使えなくなってしまう
- URIはリソースを表現する名詞にする
HTTP
名前こそハイパーテキストの転送用プロトコルだが、実際にはHTMLやXMLなどのハイパーテキストだけでなく、静止画・音声・動画・JavaScriptプログラム・PDFや各種オフィスドキュメントファイルなど、コンピュータで扱えるデータであれば何でも転送できる。
HTTPはRESTの重要な特徴である統一インタフェース、ステートレスサーバ、キャッシュなどを実現している、Webの基盤となるプロトコルである。
べき等性と安全性
HTTPメソッドはその性質によって以下の様に分類できる。
| メソッド | 性質 |
|---|---|
| GET、HEAD | べき等かつ安全 |
| PUT、DELETE | べき等だが安全でない |
| POST | べき等でも安全でもない |
べき等とは
「ある操作を何回行っても結果が同じこと」を意味する数学用語。
例えばPUTやDELETEを同じリソースに何回発行しても、必ず同じ結果（リソースの内容が更新されている、リソースが削除されている）が得られる。
安全とは
「操作対象のリソースの状態を変化させないこと」を意味する。
リソースの状態に変化を与えることを「副作用」と言うので、安全は「操作対象のリソースに副作用がないこと」とも言う。
例えばGETには副作用がないので、GETを同じリソースに何度発行しても、リソースの状態は変化しない。
ステータスコードの意味と分類
- 1xx：処理中
- 2xx：成功
- リクエスト成功を示す。
- 3xx：リダイレクト
- 他のリソースへのリダイレクトを示す。クライアントはこのステータスコードを受け取った時、レスポンスメッセージのlocationヘッダを見て新しいリソースへ接続する。
- 4xx：クライアントエラー
- 5xx：サーバエラー
- 原因はサーバ側にある。サーバ側の原因が解決すれば、同一リクエストを再送信して正常な結果が得られる可能性がある。
キャッシュ
HTTPの重要な機能の一つ。
サーバから取得したリソースをローカルストレージ（ハードディスクなど）に蓄積し、再利用する手法のこと。
ローカルストレージにキャッシュしたデータそのもののこともキャッシュと呼ぶことがある。
クライアントが蓄積したキャッシュは、そのキャッシュが有効な間、クライアントが再度そのリソースにアクセスしようとした時に再利用する。
HTML
Hypertext Markup Lnaguageの略。
マークアップ言語とは、タグで文書の構造を表現するコンピュータ言語である。また、マークアップ言語でマークアップした構造を持った文書のことを「構造化文書」と呼ぶ。
Atom
タイトル・著者・更新日時といった基本的なメタデータを備えたリソース表現のためのフォーマット。
Atomは多様なアプリケーション用の拡張が用意されたフォーマットでもある。
例えば、ポッドキャストによる音楽配信や、写真管理、検索エンジンなどのアプリケーションは、XMLの名前空間の仕組みを使ってAtomに独自の要素を追加している。
JSON
JavaScript Object Notationの略で、データ記述言語である。
その名の通りJavaScriptの記法でデータを記述できる点が最大の特徴で、記法はJava Scriptだが、そのシンプルさから多くの言語がライブラリを用意しているため、プログラミング言語間でデータを受け渡すことができる。
Webサービスでは、ブラウザがJavaScriptを実行できるために相性が良い、XMLと比べてデータ表現の冗長性が低いなどのメリットから、Ajax通信におけるデータフォーマットとして活用されている。
Webサービス設計において大切な考え方
- なるべくシンプルに保つ
- 設計が複雑になったり機能が無駄に増えてきたら、１段階メタな視点で全体を考え直す。
やり方を変えることで削除できる箇所があるかもしれない。
全体をシンプルに保つことは、設計バランスを考える上で最も重要。
- 設計が複雑になったり機能が無駄に増えてきたら、１段階メタな視点で全体を考え直す。
- 困ったらリソースに戻って考える
- HTTPメソッドでは実現できない機能があると感じたら、それが独立した別リソースで代替できないかを考える。
検索機能を実現するSEARCHメソッドをHTTPに追加するのではなく、「検索結果リソース」をGETする、と考えることが重要。
- HTTPメソッドでは実現できない機能があると感じたら、それが独立した別リソースで代替できないかを考える。
- 本当に必要ならPOSTで何でもできる
- 更新にはPUTを用いるべきだとしても、例えばバッチ処理の様に複数リソースが対象となった時点で、PUTを使うのは諦めてPOSTを用いる方が賢明である。
まとめ
プログラミング学習を始めた頃から、Railsに触れ始めた頃からRESTという言葉やリソースを大切にする考え方に触れることは多くありましたが、そもそもそれはWebの成り立ちにも起因することで、Webが発展してきた経緯があったということを知りました。
自分がこれまで学んできたことは、どちらかといえば表層の方にすぎず、より根底に近いHTTP、URIなど開発の基礎とも言える箇所を新たな角度から学ぶことができたのではないかと感じています。
