REST APIとは?
REST API とは、一言でいうと「REST」という考え方で設計した API のことで、RESTful API と呼ばれることもあります。
Webエンジニアの方であれば「レストフルな設計をしよう」といったことを耳にする機会も多いのではないでしょうか。
そもそも、この「REST」とは Webサービスや Webアプリケーション設計の思想のひとつで、全世界で統一されたルールのことです。
そして、そのルールに従って作成した API が REST API ということです。
これだけではわかりにくいと思うので、家の設計にたとえてみましょう。
一口に家といっても、木造の一軒家や鉄筋コンクリート造のマンションまでさまざまです。
もし、あなたが家を建てようと考えた時も、木の温かみが欲しいから木造にしよう、とか、防音のために鉄造にしよう、といった、家を建てる目的によってその設計手段は異なってきます。
これと同じように、Webアプリケーションを作っていく上でも、アクセス数の多い SNS を作りたい、といった目的から、それに適した「REST」という思想を適応させて開発を進めていくというものです。
REST のほかにも設計思想はいくつかあり、かつては SOAP (Simple Object Access Protocol) や RPC (Representational State Transfer) という設計思想で設計することも多かったですが、現在は実装しやすく、汎用性の高いRESTを適応させるのが主流になっています。
そのため、REST を学ぶことで多種多様な Webサービスや Webアプリケーションに適応できます。
APIとは?
APIは「Application Programming Interface」の略で、HTTPプロトコルを使って外部サービスのデータや機能を利用するために用いられるインターフェースです。この、「インターフェース」とは、何かと何かを繋ぐものの総称で、たとえば、キーボードも人間と PC を繋ぐインターフェースです。
API もクライアントとサーバの中継ぎをするインターフェースです。昨今では、API というと、Web API を指す場合が多いですが、なかでも現在主流になっているのが「REST API」です。
Web API を利用する最大のメリットは、他社が提供する豊富なデータや機能を簡単に利用できるということです。自社で全ての機能を一から開発するにはかなりの負担がかかってしまいますが、他社が提供する既存の機能を取り入れることで開発を効率化できます。また、Web API を提供する側としても、自社のシステムを広く利用してもらうことでユーザの増加が期待できるといったメリットがあります。
APIの仕組み
API はクライアントとサーバの中継役であると紹介しましたが、詳しく説明します。
たとえば、スマホで YouTube を見ている場合、そのスマホがクライアントに相当します。
クライアントはリクエスト (HTTPリクエスト) をサーバに送ります。
このリクエストとは、正しくは HTTPリクエストといって、「https://〜」の http のことです。
URLは Web上の住所のようなもので、これを受け取ったサーバはそれに対するレスポンスをクライアントに返します。それによって、クライアントはその Webサービスを利用できるのです。
そしてこのクライアントとサーバを中継しているのが API なのです。
レストランで例えてみると、お客さんはいろんな料理が載ったメニュー表から選んで注文し、注文が入ったらシェフが料理を作り、出来上がった料理をウェイターが客に運ぶことでお客さんは食事ができます。
ここでいうお客さんがクライアント、メニュー表の中から注文を承るウェイターがAPI、シェフがサーバです、料理名がアドレスになります。
メニュー表にないものは注文できないのと同様に、あらかじめ提供する API は決まっています。
そのため、クライアントから管轄外のリクエストがくるとエラーを返します。
HTTPリクエストの構成要素
URL :リクエスト先
リクエストヘッダー:リクエストの付属情報 (リクエストに必要な秘密情報やリクエストの形式など)
リクエストパラメータ :特定キーワード
APIレスポンスの構成要素
レスポンス:JSONの形式が一般的に使われている
HTTPレスポンスコード:正常なら200
代表的なAPI
News API
News API は、世界中のニュースデータを取得する API で、特定のキーワードを含むニュースや特定のニュースソースのニュースを取得できます。
YouTube Data API
YouTube Data API は、YouTube動画を取得できる API で、特定のキーワードを含む動画や特定のチャンネル、自分のアップロードした動画の統計情報などを取得できます。
RESTとは?
REST は「Representational、State、Transfer」の頭文字をとった、システム設計における考え方です。
Representational (代表的な)
State (状態)
Transfer (転送)
これだけでは意味が分からないという方も多いと思うので、まずは REST の設計におけるルールを説明します。
先ほどの家づくりの例で行くと、この木の硬さでは使えませんよ、この木の硬さ以上だったら使えますよ、といったルールがあるように、REST にもいくつかのルールがあります。
RESTの4原則
REST にはいくつかルールがありますが、なかでも代表的な 4 つを紹介します。
この REST の 4 原則は、もともと HTTP を設計した中心人物である Roy Fielding 氏が 2000 年に論文で提唱したものに基づいています。
アドレス可能性 (Addressability)
アドレス可能性とは URL を打ち込むことでデータが返ってくる、といったように、それぞれの情報ごとに場所や名前を識別できるように表現することです。
統一インターフェース (Uniform Interface)
情報をやり取りする方法、つまりインターフェースをあらかじめ統一させてるということです。
たとえば、次のようなHTTPメソッドがあります。
HTTP標準メソッド
GET (情報の取得)
POST (情報の投稿)
PUT (情報のアップデート、編集)
DELETE (情報の削除)
クライアントがサーバに対して情報が欲しい場合はGETというメソッドを使いますが、この「GET」が統一インターフェースであり、あらかじめ、これら 4 つの HTTPメソッドを Webサービス上で使うというルールです。
ステートレス性 (Stateless)
サーバがクライアントの決済情報とかセッション情報過去の状態(情報)を保持せずに、その都度受け取った内容に対する結果を返すことです。
この逆はステートフルな状態といって、過去の情報を保持した状態のことを言います。
便利そうなステートフルな状態でなく、なぜ、わざわざステートレスなのかというと、過去の情報を保持した状態だと管理が難しく、情報の見極めや管理のコストがかかってしまうため、シンプルに統一することでコスト運用の削減や拡張性 (スケーラビリティ) が高まります。
接続性 (Connectability)
1 つの記事に複数のリンクが貼られている状態を接続性があるといいます。
REST の Representational は URL に相当し、URL によって最新状態のリソースに転送させることで、これらのルールを満たした Webサービス、Webアプリケーションを「レストフルな Webサービス、Webアプリケーション」といいます。
REST の原則に従うことで、シンプルで効率的な情報のやりとりができ、大規模でアクセスが集中するような Webサービスや Webアプリケーションの開発に適応させることが多いです。
REST APIとSOAP APIの違い
REST API と SOAP API はどちらも HTTPプロトコルを活用する点は同じですが、SOAP API は REST API よりも厳格なメッセージパターンを持つため、安全性は高いですが、負荷が大きいので REST API よりもスピード性は落ちる傾向にあります。
REST API は柔軟性に優れ、軽量でもあるためモバイルアプリケーション開発などに最適です。
REST APIのメリット
Webサービスに API を採用し、REST に従った設計にすることで通常の Webサービスと比べて次のようなメリットがあります。
- 共通の枠組みとすることで、開発者が理解し易く、利用者にとっても使いやすくなる
- HTTPメソッドを利用することで、一貫性のあるシンプルで効率的な開発ができる
- ステートレスにより、負荷に応じた拡張がしやすくなる
REST APIを使うデメリット
REST はあくまでも設計における考え方であるため、実装の規定がない分、開発者によって記述方法にばらつきが出てしまう恐れがあります。