RESTの原則
はじめに
本記事では「Webを支える技術」で学んだ内容と別途気になって調べた内容や知識も含めアウトプットしています。
書籍に記載されている内容を順序立ててまとめるというよりは、整理しておきたい周辺の知識と深ぼった内容を雑多に書いています。
REST
REST（Representational State Transfer）は、ウェブサービスの設計モデルまたはアーキテクチャスタイルとして知られています。
RESTのアーキテクチャスタイルは、Webの基本的なプロトコルであるHTTPの設計原則に基づいています。
アーキテクチャスタイル
ネットワークシステムのアーキテクチャスタイルとして最も有名なのはクライアント／サーバ（ClientServer）です。
Webはクライアント／サーバに該当し、RESTにも該当します。
クライアント／サーバアーキテクチャスタイルにいくつかの制約を加え派生したのが、RESTというアーキテクチャスタイルです。
マイクロアーキテクチャパターン
マイクロアーキテクチャパターンはデザインパターンを指します。
MVCやパイプ＆フィルタなどがあります。
アーキテクチャよりも粒度の小さいクラスなどの設計流儀を指します。
RESTの4つの原則
アドレス可能性 (Addressability)
アドレス可能性とは URL を打ち込むことで、サーバはその要求に対して適切なレスポンス（通常は該当リソースの表現）を返すといったように、それぞれの情報ごとに場所や名前を識別できるように表現することです。
統一インターフェース (Uniform Interface)
クライアントとサーバー間の相互作用が簡素化され、独立して進化することが可能になるように統一されている状態を指します。
Webサイトでは4 つの HTTPメソッドを使うというルールがあります。
- GET
- POST
- PUT / PATCH
- DELETE
HTTPメソッド（GET、POST、PUT、DELETE）は、リソースに対する操作を表現するための統一されたインターフェースの一部です。これにより、クライアントは一貫した方法でリソースに対して操作を行うこと
ステートレス性 (Stateless)
サーバがクライアントのセッション情報過去の状態（情報）などを保持せずに、各リクエストが完全に独立しており、前後のリクエストとの関連性が無いことを意味します。
対して過去の情報を保持した状態をステートフルといいます。
ステートレスな設計では、各リクエストはそれ自体が全ての必要な情報を含んでいるため、リクエストを処理するためにはサーバーが過去のリクエストを覚えておく必要はありません。これにより、システムはより安定し、スケーラブルになり、障害に対する耐性が向上します。
接続性 (Connectability)
接続性とは、基本的には、システム内の情報がどのようにリンクされ、参照されるかを指します。
これはWebにおけるリンクの使い方を考えると理解しやすいです。
ウェブページには他のウェブページへのリンクが含まれており、それらのリンクをたどることで情報を見つけたり、関連する情報にアクセスしたりします。
例）ある商品の情報を表すリソースがあり、そのリソース内に製造元の情報を表す別のリソースへのリンクが含まれているとします。
ここでの「接続性」は、商品リソースから製造元リソースへのリンクを通じて実現されます。
これにより、クライアント（ユーザーやシステム）は商品リソースを取得した後、そのリンクをたどって製造元の詳細な情報を容易に取得できます。
実は6つの原則がある？
下記は、RESTの生みの親であるロイ・フィールディング氏の原著論文「Architectural Styles and the Design of Network-based Software Architectures」（2000年発表）です。
https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
上記の論文によると「アーキテクチャーを導き出したプロセス」としてセクションが６つあるため、こちらをまとめたいと思います。
クライアント-サーバーモデル
RESTの基本的な構造はクライアントとサーバーの間の相互作用に基づいています。
クライアントはリクエストを行い、サーバーはそれに対するレスポンスを提供します。
このモデルでは、クライアントとサーバーは互いに独立して進化し、それぞれが他方を知らずに変更されることが可能です。
ステートレス
すべてのクライアントリクエストは、それぞれが独立したトランザクションとして扱われます。
これは、サーバーがリクエスト間でクライアントの状態情報を保持しないことを意味します。
これにより、スケーラビリティと信頼性が向上します。
キャッシュ可能
クライアントはレスポンスをキャッシュできるため、再利用可能です。
これにより、レスポンスの再利用が可能になり、クライアントとサーバーの間の相互作用を減らし、パフォーマンスを向上させます。
レイヤードシステム
クライアントは通常、エンドポイントと直接通信しますが、それが直接の通信であるか、中間層を通じたものであるかを知る必要はありません。
これにより、システムの複雑さが隠蔽され、様々な種類のネットワーク構成が可能になります。
コード・オン・デマンド（オプション）
必要に応じて、サーバーは実行可能なコードをクライアントに送信することができます。
これにより、クライアントの機能を一時的に拡張することができます。
一貫したインターフェース
RESTは、リソース（ウェブサービスで利用可能なアイテムやデータ）へのアクセスを、一連の単純で予測可能な操作（通常はHTTPメソッド）を使用して提供します。
これにより、開発者はシステムの動作を容易に予測でき、ウェブサービスとやり取りするためのコードを簡単に記述できます。
これらの原則に従うことで、開発者はスケーラブルで高性能、メンテナンスしやすいウェブサービスを作成できます。ウェブAPI、特にHTTP上で公開されているAPIの設計に、広く採用されています。
参考
おしまい
コメント
本記事の内容は以上になります！
書籍の続きのアウトプットも随時更新したいと思います。
プログラミングスクールのご紹介 (卒業生より)
お世話になったプログラミングスクールであるRUNTEQです♪
こちらのリンクを経由すると１万円引きになります。
RUNTEQを通じて開発学習の末、受託開発企業をご紹介いただき、現在も双方とご縁があります。
もし、興味がありましたらお気軽にコメントか、TwitterのDMでお声掛けください。
