クライアント・サーバーモデルの拡張であり、分散システムにおいて複数のソフトウェアを連携させるのに適した設計原則の一つ。2000年にロイ・フィールディング（Roy Fielding）氏が提唱した。

RESTはWeb上の情報（リソースと呼ばれる）をURIで識別し、HTTPメソッドで操作する。この仕組みが広く受け入れられた結果、RESTは分散システムの設計方法として世界的に使用されるようになった。

今回の講義でもこのRESTを使ったAPIを作成するため、本章ではRESTの設計原則について説明する。

ℹ️

補足: RESTが主流になった経緯
RESTが流行する前はSOAPやWS-*など、仕様が乱立していた。2003年、AWSがSOAP形式とREST形式の両方を利用したAPIを提供したところ、利用率がSOAP:REST = 2:8であったと報告された。その後RESTが主流となり、現在ではほとんどのWeb APIがRESTに基づいている。

https://www.amazon.co.jp/dp/4774142042

RESTは以下6つの設計原則で構成される。記事によっては4つに集約されて紹介されることもあるが、正式には6つ。

• 何を言っているか
  • クライアント（画面表示・ユーザー操作）とサーバー（データ管理・ビジネスロジック）を分離する
• なぜ重要か
  • それぞれが独立して開発・改善できる。フロントエンドを作り直してもバックエンドは変わらない

• 何を言っているか
  • サーバーはクライアントの状態を保持しない。各リクエストには処理に必要な情報が全て含まれている必要がある
• なぜ重要か
  • サーバーが状態を持たないため、リクエストをどのサーバーに振っても同じ結果が返る。サーバーの台数を増やすだけでスケールアウトできる
• 現実との折り合い
  • 完全なステートレスではECサイトのカート機能などが実現できない。実際にはJWTやCookieを使ったセッション管理と組み合わせて運用される。REST原則としては「できるだけステートレスに保つ」という方向性と理解すればよい

• 何を言っているか
  • サーバーからのレスポンスがキャッシュ可能かどうかを明示する
• なぜ重要か
  • 同じリクエストを何度も送る必要がなくなり、通信量が減る。ユーザー体験が向上する
• 注意点
  • 古いキャッシュを使い続けると、更新されたデータが表示されない問題が起きる。適切なキャッシュ期間の設定が必要

• 何を言っているか
  • リソースに対する操作を、HTTPメソッド（GET/POST/PUT/PATCH/DELETE）という限定的で統一された方法で行う
• なぜ重要か
  • インターフェースが統一されているため、どのAPIでも使い方が予測できる。「商品を取得するならGET、作成するならPOST」というルールがどのサービスでも共通する

• 何を言っているか
  • クライアントとサーバーの間にロードバランサ、プロキシ、キャッシュサーバーなどの中間層を挟める
• なぜ重要か
  • クライアントから見ると接続先がサーバーでもプロキシでも同じHTTPで通信するため、中間層の存在を意識する必要がない。負荷分散やセキュリティ対策を透過的に追加できる

• 何を言っているか
  • サーバーからクライアントにプログラムコードを送り、クライアント側で実行できる
• なぜ重要か
  • JavaScriptのように、クライアントで動的に処理を追加できる。サーバーと毎回通信しなくても一部の処理をクライアントで完結できる
• 注意点
  • この原則はオプション扱い。全てのRESTful APIが実装する必要はない

RESTとは以下6つを組み合わせたアーキテクチャスタイルである。

• クライアント/サーバー
  • ユーザインターフェースと処理を分離する
• ステートレス
  • サーバ側でアプリケーション状態を持たない
• キャッシュ制御
  • クライアントとサーバの通信回数と量を減らす
• 統一インターフェース
  • インターフェースを固定する
• 階層化システム
  • システムを階層に分離する
• コードオンデマンド
  • プログラムをクライアントにダウンロードして実行する

RESTを名乗る上で基本的に満たす必要がある。
ただし実際の開発では、ステートレス原則などを完全に守らず実用性とのバランスをとる場面もある。