参考
https://lukesilvia.hatenablog.com/entry/20091025/p1 https://qiita.com/NagaokaKenichi/items/0647c30ef596cedf4bf2 https://qiita.com/NagaokaKenichi/items/df4c8455ab527aeacf02 https://qiita.com/NagaokaKenichi/items/0f3a55e422d5cc9f1b9c https://www.sakimura.org/2011/11/1289/ https://qiita.com/mserizawa/items/b833e407d89abd21ee72 https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
RESTful APIとは
RESTの原則に則って構築されたWeb APIのこと
そもそもWeb APIとは
参考サイトには
厳格な定義はないが、広義にはHTTPプロトコルを用いてネットワーク越しに呼び出すアプリケーション間、システム間のインターフェースのこと。
とあります。
APIは「Application Programming Interface」なので結構広義な言葉ですね。
個人的には
みたいなイメージで理解しています。
RESTとは
Web APIについて調べると避けては通れないのがRESTの概念です。
セットで登場することが多いですがRESTというのはWeb APIのためだけの考え方ではないようです。
RESTはWebのアーキテクチャスタイルです。
アーキテクチャスタイルとは、複数のアーキテクチャに共通するパターンのようなものです。
デザイン(設計)とデザインパターンの関係と抽象度的には近いと思います。
例えば、MVC
もアーキテクチャスタイルです。具体的なアーキテクチャより抽象度がひとつ高いイメージです。
RESTは、ネットワークシステムのアーキテクチャスタイルです。
ネットワークシステムのアーキテクチャスタイルとして有名なのはクライアント/サーバ
ですが、RESTはこれから派生したものです。
素のクライアント/サーバ
スタイルにいくつかの制約を加えたものがRESTというアーキテクチャスタイルです。
抽象度のレベル | Webにおける例 |
---|---|
アーキテクチャスタイル | REST |
アーキテクチャ | ブラウザ,HTTP,URI,HTML |
実装 | Firefox,IE,Apache |
RESTはWeb全体のアーキテクチャスタイルでもあり、個別のWebサービスやWeb APIのアーキテクチャスタイルでもあ理ます。
以下、具体的にRESTの内容について見ていきます。
RESTにおける重要な概念の一つにリソースというものがあります。
「リソース指向アーキテクチャ」という概念があり、RESTを語る上で重要なので以下参照先を読んで先に理解しておくとRESTの理解がスムーズそうです。 https://qiita.com/NagaokaKenichi/items/0f3a55e422d5cc9f1b9c
リソースとは、Web上に存在する、名前を持ったありとあらゆる情報のことです。
この名前がWebの場合はURI
です。
ただし、1つのリソースは複数のURIを持つことができます。
例えば、
のような二つのURIは同じリソースを指します。 一方は「今日」の情報、一方は「4月25日」の情報を指しているため、それぞれのURIの指す意味は異なります。
このようにURIに別名をつけると、クライアントがリソースにアクセスしやすくなる反面、どれが正式なURIなのかが分かりにくくなってしまう欠点もあります。
RESTの原則について
RESTは主に以下の4つの原則から成り立っています。
ですが原著である以下リンクには特に4つの原則という記述はなかったのでどこから4つの原則になったのか不思議(また調査しておきます)。
https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1
ちなみにリンク内には以下のようなキーワードで記載があります。
- Client-Server(クライアント-サーバー)
- Stateless(ステートレス)
- Cache(キャッシュ)
- Uniform Interface(統一インターフェース)
- Layered System(階層的システム)
- Code-On-Demand(オンデマンドコード)
一旦、上記のキーワードについては置いておいて、RESTの原則について説明します。
一般的にはRESTの原則とは以下の4つの原則です。
アドレス可能性 Addressability
ステートレス性 Stateless
- HTTPをベースにしたステートレスなクライアント/サーバプロトコルであること。セッション等の状態管理はせず、やり取りされる情報はそれ自体で完結して解釈できること。
簡単にいうとやり取りするメッセージ内にそれまでのやり取りの情報も含めることでサーバーが状態を持たなくても結果が導き出せること。
- HTTPをベースにしたステートレスなクライアント/サーバプロトコルであること。セッション等の状態管理はせず、やり取りされる情報はそれ自体で完結して解釈できること。
接続性 Connectability
- 情報の内部に、別の情報へのリンクを含めることができること。
統一インターフェース Uniform Interface
- 情報の操作(取得、作成、更新、削除)は全てHTTPメソッド(HTTPメソッドは8個あるが、主にGET、POST、PUT、DELETE)を利用すること。
RESTful APIのメリット
RESTfulなAPIにすることのメリットについて考えてみます。
いい設計原理への誘導
前述したようにRESTとは、一種の制約です。
つまりこの制約に従う際に苦痛を感じた時、それはWebの自然なアーキテクチャとしての設計が間違っていることを示唆しています。
統一性
RESTに従うことで、統一性が生まれます。その統一性は標準化作業に大きく貢献し、システム間での連携をしやすくします。シンプルかつ一貫性のあるリクエストの標準化が円滑に行えます。
スケーラビリティ
ステートレス性を保つため、負荷に応じて水平方向へスケールしやすいです。
簡単に説明すると、スケーラビリティとは負荷に応じて対応することを指していて、垂直方向はサーバーの処理能力を向上させること、水平方向というのはサーバーの台数を増やすことを指しています。
ステートレス性のおかげで、サーバーが状態を保つことはないため、サーバーを増やす、つまり水平方向へのスケールがしやすいです。
キャッシュ
RESTを通じてHTTPキャッシュを利用することができます。 HTTPキャッシュの要件には「透過性」があり、キャッシュが関与しているいないに関わらず転送される情報が同じになることが意識されています。
利点はサーバーとクライアントの間の通信を減らすことでより効率的に処理できることです。
RESTを用いた設計
リソース指向
RESTfulなAPIやWebアプリケーションの設計はURIの設計が大部分を占めます。
URIごとに何をやるかはHTTPメソッドにて定義されていますし、名前も決められています。
RESTにおいては、「その処理によって得られるリソース」に注目して設計を行います。
これが「リソース指向アーキテクチャ」のことですね。
この辺りは以下参照リンクがとても参考になると思いました。 https://qiita.com/mserizawa/items/b833e407d89abd21ee72
HTTPメソッドに対する正しい設計
HTTPメソッドには、以下のような性質があります。
メソッド | 性質 |
---|---|
GET,HEAD | べき等かつ安全 |
PUT,DELETE | べき等だが安全でない |
POST | べき等でも安全でもない |
べき等とは...ある操作を何回行っても結果が同じこと
基本的にこの性質を逸脱する使い方をしてはいけません。(HTTPメソッドの仕様上、可能だがするべきではない)
ちなみに、リソースの作成については、POSTでもPUTでも行うことができます。 この場合の使い分けは、以下のように考えます。
- クライアントがリソースのURLを既に知っている場合はPUT
- サーバーがURLを決定する場合はPOST
POSTの場合、クライアントはリソースのURIを指定できないことから上記の考え方が望ましいです。
PUTの場合はサーバの内部実装を意識しないといけないため、どうしてもサーバとの結合が密になってしまう点に注意が必要です。(URIにどの文字を許すかなどの制限を知っている必要がある)
まとめ
RESTとは、以下の4つの原則から成り立つアーキテクチャスタイルです。
- アドレス可能性 Addressability
- ステートレス性 Stateless
- 接続性 Connectability
- 統一インターフェース Uniform Interface
他にも、以下のようなキーワードがRESTにおいて重要です。
- Client-Server(クライアント-サーバー)
- Stateless(ステートレス)
- Cache(キャッシュ)
- Uniform Interface(統一インターフェース)
- Layered System(階層的システム)
- Code-On-Demand(オンデマンドコード)
これらRESTの考え方に則ったAPIをRESTful APIといいます。
当たり前ですが、RESTに明らかに向いていない場合は他のアーキテクチャスタイルを考えるべきです。
たとえば、他にもSOAPなどのスタイルがあります。
こちらについてもまた調べてみたいと思います。
所感
個人的に今回色々調べる中で、「APIは開発者のためのUIです。」というひとことにかなり納得しました。
ぱっとみて理解できる、想像しやすい、使い易いAPIを設計する上で、RESTの考え方を意識して設計することで理想に近づけるのかなと思いました。
特にどんなリソースに対しても、HTTPメソッドで操作するという統一インタフェース
のおかげでどんなサービスでもある程度想像しやすいつくりになると思います。
以前、クリーンアーキテクチャの記事を書いたときに以下のような記述をしました。
- プログラミングは自由。何でもできる。でも、サービスを作る上では方針をある程度決めておくといろんな事象に対応しやすいし、スムーズに開発できるよね。っていうイメージ。
RESTもまさしくこれに当てはまると思います。 Webをはじめ、さまざまなサービスが統一して一定の制約を守ることで連携しやすい、使いやすいシステムの構築が容易になります。