REST API理論

最初のモジュールは、HTTPリクエストを作成し、それを送信し、レスポンスを取得することで終了しました。

これから先も何度もこのようなことをすることになります。サードパーティのサーバーにリクエストを送ることもあります。自分自身がそのようなリクエストを受け取り、レスポンスを返すアプリケーションを作る。リクエストを処理するための複雑なロジックを作成する。

ですから、このようなリクエストに関することは、徹底的に勉強して、細かく分析しておくとよいでしょう。ただ単にリクエストをどこかにコピーして繰り返すのではなく、それがどのような仕組みになっているのかを本当に理解することができるように。

これが、2番目のモジュールで行うことです。さあ、始めましょう。

一般論

理論から始めましょう。

最初のモジュールで宿題をして、ドキュメントを勉強したのなら、APIという頭文字に気づいたはずです。実は、ネットワーク上の何らかのサービスやアプリケーションとのインタラクションを理解したい場合、開発者が最初に勉強すべきなのはAPIドキュメントなのです。

API

API - Application Programming Interface（アプリケーション・プログラミング・インターフェース）。これは、クライアントとサーバーが相互に通信するための方法を記述したものである。私たちはAPIのドキュメントを開き、そこからサーバーから必要なデータを取得する方法を学びます。

私たちは常に、このやり取りがシンプルで理解しやすいものであることを望んでいます。これにより、開発者（新しいサービスを設計する際に車輪の再発明をする必要がない）とユーザー（以前に慣れ親しんだサービスと同じ原理で動作する場合、サービスははるかに容易に習得できる）の両方にとってタスクが簡素化されます。ここで、新しい用語であるRESTを覚えておくとよいでしょう。

REST

RESTとは、Representational State Transferの頭文字をとったものです。あまりピンとこないかもしれませんが、簡単に言うと、RESTはクライアントとサーバーの間のインタラクション（情報交換）のスタイルです。

これは、何か厳格な規則や要件のセットではありません。RESTは、特定のプログラミング言語の使用を強制するものでもなければ、厳格なガイドラインで手を縛るものでもない。RESTはアーキテクチャのスタイルと呼ばれ、システムアーキテクチャが遵守すべき6つの原則を定義している。

したがって、RESTの原則を踏まえて開発されたAPIをREST APIと呼び、そのアプリケーション自体をRESTfulと呼びます。

今回はそのようなRESTfulなアプリケーションを作成しますので、早速、その原則について説明します。

RESTfulの原則

クライアント・サーバー・モデル。この原則では、クライアントとサーバーの分離、ニーズの差別化を定義しています。クライアントは、データがどのように保存されるかを気にする必要はなく、要求に応じてデータが発行されることが重要です。一方、サーバーは、クライアントがこのデータをどのように処理し、どのように表示するかは気にしない。そのため、互いに独立した開発が可能となり、システムのスケーラビリティが向上する。

ステートレス。この原則は、サーバーがこのクライアントとの過去の経験に基づいてレスポンスを「考え出す」べきではないことを意味します。どのようなリクエストも、以前のリクエストに関係なく、その処理に必要なすべての情報を含むように行われます。

キャッシュする。送信データを最小限にするために、キャッシュの仕組みがあります。例えば、あるページにロゴが表示されている場合、それを毎回サーバーにリクエストするのは意味がない。ロゴは頻繁に変わるものではないので、一度取得して、クライアントのコンピュータのキャッシュに保存しておけば十分である。しかし、車の現在の速度についての情報を得る必要がある場合、キャッシュは何の役にも立たない。この原則は、サーバーから送信されるデータをキャッシュ可能かどうか指定することを決定する。

統一されたインターフェース。この原則は、クライアントとサーバーのやりとりの形式を統一することを定義しています。すべてのリクエストの構造は同じでなければなりません。データは、誰が要求しても同じ形式で送信されなければならない。

レイヤーシステム。クライアントとサーバーは必ずしも直接通信するわけではありません。データ転送はいくつかの中間ノードを経由することもある。この場合、クライアントもサーバーも、最終的なアプリケーションとやりとりしているのか、中間ノードとやりとりしているのかがわからないようなシステムになっています。これにより、サーバーの負荷分散、スケーラビリティの向上が可能になります。

コードオンデマンド（オプション）。唯一、必須ではない原則。これによると、クライアントはサーバーから実行可能なコード（例えばスクリプト）をダウンロードすることで機能を拡張することができる。この場合、コードはオンデマンドでのみ実行される必要があります。