『REST入門』Webの設計思想であるREST

OpenAPI(Swagger) REST

ここではWebという巨大なシステムがどのように動作しているのか。
それを知るためにWebの設計思想であるRESTについて記載しています。

Webの仕様策定(RFC)

1990年代半ばから後半にかけてWebの普及したことにより、Webを構成する技術としてHTTPとURI、HTMLなどの標準化が求められました。

これらはサーバとクライアントの間で利用され、相互運用性が求められたためです。

Web以前のインターネット標準はすべてIETF(Internal Engineering Task Force)のRFC(Request for Comments)として定められてきました

しかし、あまりにも爆発的に普及したため、IETFでの仕様策定が追いつかなくなり、相互運用性が欠ける状態が発生しました。

このような問題を解決するため、1994年にBerners-Leeが中心となりWeb技術を実装している各社が集まって標準化する団体である、W3C(World Wide Web Consortium)を設立しました。

W3Cでは、HTML、XML、HTTP、URI、CSSなどの標準化作業が行われ、HTTPとURIは、W3CとIETFがワーキンググループとなり、RFCとして仕様がまとめられました

 

RESTの誕生

カリフォルニア大学アーバン校の大学院生だったRoy Fielding(ロイ・フィールディング)は、Webがなぜこんなにも成功したのか、なぜこれほど大規模なシステムが成立したのかについてソフトウェアアーキテクチャの観点から解析を行い、1つのアーキテクチャスタイルとしてまとめました。

2000年、Fieldingはこのアーキテクチャスタイルを「REST」(Representational State Transfer)と呼び、博士論文として提出します。

HTTPはもともとハイパーテキストを転送するためのプロトコルでしたが、実際はハイパーテキスト以外の様々なものを転送しています。それは「リソースの状態」(Resource State)の「表現」(Representation)であるため、Representational State Transferと名付けたのです。

 

RESTとは

RESTはWebのアーキテクチャスタイルです。

実際のシステムは具体的なアーキテクチャを持っています。

そのアーキテクチャを設計するときに、独自の考えで作っていくのではなく、アーキテクチャ設計の方針、作法、ルールつまり、アーキテクチャスタイルを適用します。

システムのアーキテクチャを決定する際の設計思想となるのがアーキテクチャスタイルです。

つまりRESTとは、WebアプリやWeb APIシステムを設計する際の設計思想のことです。

RESTは数あるアーキテクチャスタイルの中でも、特にネットワークシステムのアーキテクチャスタイルになります。

ネットワークシステムのアーキテクチャスタイルとして際も有名なのはクライアント/サーバです。
そして、Webはクライアント/サーバでもあります。

RESTは、クライアント/サーバから派生したアーキテクチャスタイルで、素のクライアント/サーバアーキテクチャスタイルに幾つかの制約を加えていくと、RESTというアーキテクチャスタイルになります

RESTはWeb全体のアーキテクチャスタイルでもあり、個々のWebサービスやWeb APIのアーキテクチャスタイルでもあります。

個々のWebサービスやWeb APIで、RESTの制約を守ることが重要になります。

 

リソース

RESTにおける重要な概念の一つにリソース(Resource)があります。

RESTを理解するためにはリソースについての理解が必要です。

RESTの解説に入る前にリソースについて説明します。

まずはWebにおけるリソースを例に見てみましょう。
・東京の天気予報
・筆者のホームページにあるペットがスイカを食べた時の日記

上記はいずれもリソースです。Web上には数えきれないほどのリソースが存在します。

リソースを一言で説明すると、「Web上に存在する、ユニークな名前を持ったさまざまな情報」となります。

では、リソースが名前を持つとはどういうことでしょうか。

そもそも、ものの名前(名詞)には、他のものと区別して指し示す役割があります。

リソースの名前とは、あるリソースを他のリソースと区別して指し示すためのものです。

 

リソースとURI

リソースの名前とはURIのことです。

先ほどのリソースは、それぞれ次のようなURIで識別します。

・東京の天気予報
 https://weather.yahoo.co.jp/weather/13/4410.html
・筆者のホームページにあるペットがスイカを食べた時の日記
 https://nikukyulog.com/pet/diary/watermelon/

ここまでまとれると、

・リソースとは、Web上の情報である
・世界中の無数のリソースは、それぞれURIで一意の名前を持つ
・URIを用いることで、プログラムはリソースが表現する情報にアクセスできる

 

リソースのアドレス可能性

URIが備える、リソースを簡単に指し示す性質のことを「アドレスの可能性」(Addressability)と呼びます。

リソースにきちんと名前がついており適切な手段でアクセスできる状態にすると、プログラムを作りやすくなります。

 

複数のURIを持つリソース

1つのリソースは複数のURIを持てます。

たとえば、今日が2019年8月10日の場合の天気図を例に挙げると、次の2つのURIは同じリソースを指します。

・https://weather.yahoo.co.jp/weather/chart/
・https://weather.goo.ne.jp/past/chart/20190810/

2019年8月10日の時点では同じリソースを指しますが、それぞれのURIは意味が異なります。

一つ目が、今日の天気図で二つ目が2019年8月10日の天気図を指すURIになります。

なので、日付が変われば指し示すリソースは変わります。

リソースに別のURIを付けると、クライアントがリソースにアクセスしやすくなります。

その反面、どれば正式なURIか分かりにくくなる欠点が出てきます。

 

リソースの表現と状態

リソースは「Web上に存在する情報」という抽象的な概念です。

サーバとクライアントの間で実際にリソースをやり取りするときには、何らかの具体的なデータを送信し合います。

サーバとクライアントの間でやり取りするデータのことを「リソースの表現」(Resource Representation)と呼びます。

1つのリソースは複数の表現を持ってます。例えば天気予報リソースは、HTML形式はもちろん、テキスト形式でもPDFでも画像でも表現できます。

また、リソースには状態があります。時間の経過に従ってリソースの状態が「晴れ」であったとしても、数時間後には「嵐」に状態が変化しているかもしれません。

 

複数のアーキテクチャスタイルを組み合わせてRESTを構成する

RESTは複数のアーキテクチャスタイルを組み合わせて構成された複合アーキテクチャスタイルです。

クライアント/サーバに他の次の5つのアーキテクチャスタイルを追加して制約を課すことで、RESTを構成します。

以下が6つのアーキテクチャスタイルになります。

・クライアント/サーバ
・ステートレスサーバ
・キャッシュ
・統一インターフェース
・階層化システム
・コードオンデマンド

しかし、RESTに基づいたアーキテクチャを構築する場合でも、RESTを構成するスタイルのうち、いくつかを除外しても構いません

たとえば、ステートレスではないが、その他がRESTの制約に従っているアーキテクチャも考えられます。

それはまさに設計作業になります。ソフトウェアやシステムの設計ではアーキテクチャスタイルの理想から妥協しなければならないところも出てくるでしょう。

理想を念頭に置きながら、実際に動作して価値を提供できるシステムを作ることが重要です。

ほとんどの、RESTのスタイルを除外しなければならない場合は、そのシステムに合った別のアーキテクチャスタイルを採用することをお勧めします。

 

クライアント/サーバ

WebではHTTPでクライアントとサーバが通信するクライアント/サーバのアーキテクチャスタイルを採用しています。

クライアントはサーバに対してリクエストを送り、サーバはそれに対してレスポンスを返します。

メリットは、クライアントとサーバに分離して処理できることです。

これによりクライアントをマルチプラットフォームにできます。(PC、携帯電話、ゲーム機などからアクセスできる)

また、ユーザインターフェースはクライアントが担当し、サーバはデータストレージとしての機能だけを提供すればよくなります。

更に、複数のサーバを組み合わせて冗長化することで、可用性を上げられます。

 

ステートレスサーバ

クライアントのアプリケーション状態をサーバで管理しないことを意味します。

サーバ側で状態を管理しない為、クライアントはリクエストごとに全ての情報を送信します。

メリットは、サーバ側の実装を簡略化できることです。

これにより、サーバはクライアントにレスポンスを返した後、サーバのリソースを解放できます。

 

キャッシュ

キャッシュとは、一度取得したリソースをクライアント側である程度の期間保持して使いまわす方式です。

メリットは、クライアントとサーバの間の通信を減らすことでネットワーク帯域や処理時間を縮小できることです。

デメリットは、古いキャッシュを利用してしまい、情報の信頼性が下がる場合があります

 

統一インターフェース

URIで指定したリソースに対する操作を、統一されたメソッドで行うアーキテクチャスタイルのことです。

HTTPではGETやPOSTなどのメソッドが定義されており、通常はこれら以外のメソッドは使えません。

メソッドを限定することで、全体のアーキテクチャがシンプルになります。

 

階層化システム

統一インターフェースのメリットの一つに、システム全体が階層化しやすくなっています。

Webサービスでは、サーバとクライアント間にロードバランサを設けて負荷分散したり、プロキシを設けてアクセス制限したりしますが、クライアントからするとサーバもプロキシも同じインターフェースで接続できるので意識せずにリクエストを送ることができます。

 

コードオンデマンド

プログラムをサーバからダウンロードし、クライアント側で実行するアーキテクチャスタイルのことです。

JavaScriptやFlashなどがこれに該当します。

メリットは、クライアントを後から拡張できることです。クライアントはあらかじめ用意した機能だけではなく、新しい機能を追加していけます。

デメリットは、クライアント/サーバの間でやり取りされたリソースの内容が不明確になります。

 

RESTの意義

RESTはWeb全体のアーキテクチャスタイルになります。

私たちが作るWebサービスやWeb APIはWebを構成する一部です。個々のWebサーバやWeb APIがRESTの制約に従ってRESTらしくなる(RESTfulと、Web全体としてよりよくなります。

別の記事で、URI、HTTP、そしてHTMLなどのハイパーメディアをどのようにRESTfulに使うか、WebサービスやWeb APIをRESTfulに設計するにはどうするべきかについて書きます。

その前に、URI、HTTP、HTMLなどを勉強する上でRFCという言葉が出てくるので以下で少し説明します。

 

タイトルとURLをコピーしました