こちらの記事は随時更新中
はじめに
ネット上でエンジニア初心者に対してよく勧められている本だったので随分前から気になっていましたが中々重い腰が上がらず。業務でHTTP通信を取り扱うことが徐々に増え、どういったレスポンス、リクエストを行うのが望ましいのか
設計する上で気になったので重い腰を上げて我慢して読んでみました。
目次
-
2, URIの設計
- 2-1, クールURIは変わらない
- 2-2, URIの不透明性
1, WebのアーキテクチャスタイルとしてのREST
1-1, REST
REST とは クライアント/サーバ から派生したアーキテクチャスタイルのこと。
クライアント/サーバ とはサービスやリソースを要求するクライアントとそれに応えるサーバーが通信を行うアーキテクチャのことらしい。
サーバーの実例で私に馴染み深いところをあげると、、、
・Webサーバー (Apache HTTP Server, nginx等)
・データベースサーバ(MySQL, PostgreSQL等)
がある。他にもメールサーバーやFTPサーバーがあるがここでは割愛。
こういったサーバーとクライアントのやりとりに様々な制約を加えていくことでRESTというアーキテクチャが形作られていくようだ。
1-2, リソース
REST における重要な概念の一つにリソースがある。
リソースを簡潔に表すと「Web上に存在するありとあらゆる名前を持った情報」とのこと。
以下、リソースの例
・東京の天気予報
・ある学術論文
・ブックマーク
そしてこれらのWeb上に存在する情報が持つ名前というのが、URIを指す。
これらの名前は世界で一意である。
URIを使用することによってリソースに簡単にアクセスできる性質のことを「アドレス可能性」という。
1-3, RESTの構成
1-1でクライアント/サーバーアーキテクチャに様々な制約を追加していくことでRESTを作っていくと伝えたが下記で
その追加する制約について述べていく。
(1)ステートレス
クライアントアプリケーションの状態(セッション状態)をサーバー側で管理しないこと。各通信は独立した情報を持っておりサーバー側は今まで行った通信と全く関係のないものとして処理する。よってサーバー側の実装はリクエストに対する処理に集中でき、実装が簡潔になる。
(2)キャッシュ
一度サーバーから取得したリソース(サイトの画像など)をクライアント側で使い回すのに役立つ。通信回数が減るのでパフォーマンス的にメリットはあるが古いリソース情報を使いまわさないように注意。
(3)統一インターフェース
→ HTTPメソッドに見られるように通信方法を制限することでアーキテクチャがシンプルに。また通信方法を統一することでよりクライアント、サーバーの独立性が増し、クライアントの種類に依存せずにサーバー側はリソースを提供できる。
逆にクライアント側は統合インターフェースさえ守っていれば様々なサーバーと通信が可能になる。
(4)階層化システム
統一インターフェースによって実現ができる。各クライアントやサーバーは統一インターフェースで定められた方法で通信を行うため、クライアントとサーバーの間にプロキシサーバーを挟んだり、統一インターフェースを実現していないレガシーなシステムの前に統一インターフェースを実現したアプリケーションを挟むことでクライアントからレガシーシステムに通信が可能になる。
(5)コードオンデマンド
プログラムコードをサーバーからダウンロードしてクライアント側で実行するアーキテクチャスタイル。JavascriptやFlash, Javaアプレット」が該当する。
2, URIの設計
2-1, クールURIは変わらない
・プログラミング言語に依存した拡張子はURIに使用しない。プログラミング言語の選定が切り替わった際にURIを変更せざるをえないので。
・メソッド名やセッションIDを含めない。リファクタリングした際にメソッド名が変わったり処理内容が変更になる恐れがある。またセッションIDを使用することでURIはログインの度に切り替わってしまう。
もしURIを変更したい場合は古いURIにリクエストが飛ばされたら新しい変更後のURIにリダイレクトさせると良い。
2-2, URIの不透明性
ユーザーが直接URIを叩かないようにするべき。
例えばPDFリソースを提供するURIが下記の通りあった場合、ユーザーはPDF以外にHtmlリソースがあるかも、と推測し
拡張子を.pdfから.htmlに書き換えて直接叩くかもしれない。
・PDFリソースを返すURI
http://example.jp/press.pdf → http://example.jp/press.html
このような操作が行われるのはシステムの停止につながる恐れがあるため、あまり好ましくない。ユーザーからはリソース構成を推測しにくいURI設計を心がけるべき。