ume

REST APIについて

REST APIとは?

⇨RESTというルールに基づいてAPIを使用可能にすること

そもそもAPIとは?
⇨便利機能(google mapなど)を外部(地球上のみんなに)に提供(好きに使ってもいいよと機能を公開)すること.

通常google mapはgoogle mapのアプリ上でしか使用できない。
ただGoogleAPIを公開してくれているおかげで↓のように食べログのサイト上でもgoogle mapが使用可能になっている。

上記のように自分のアプリ上でAPI(Google mapなど)を使用可能にするために PCとサーバー間では下記のように通信が行われている↓

①この機能(google map)使わせてーとpcからサーバーにリクエストが送られる(get/post形式の標準webリクエスト方式).
②サーバーからJson形式のファイルでレスポンス(はいよ〜)される(jsonxmlといった標準データフォーマットで返却).

上記の①と②のようにデータの受け渡しをする際はRESTという下記の6つのルールを守り送受信することが推奨されている.

  • クライアント/サーバーアーキテクチャ

  • ステートレス

  • 統一インターフェース

  • キャッシュ

  • 階層型構造

  • コードオンデマンド

上記のことからREST APIとは「RESTという6つのルールを守りながら自分のアプリ上でAPIを使用可能」にすること

クライアント/サーバーアーキテクチャ

⇨クライアント側(左)がリクエストを送りサーバー側(右)はリクエストが来るまで何もしないという関係性

こうするメリット.
マルチプラットフォーム(PCやスマホなど)に対応できる.

マルチプラットフォームとは?
⇨異なる機種(iphone,ipad,Android,pcなど)やOSでも、同じアプリケーションの動作が可能

ステートレス

⇨サーバー側がクライアントの状態を把握していない状態

クライアントの状態を把握していない状態とは?要は前の通信(会話)の内容を覚えていない.

通信を靴屋さんの会話に例えてみる

pc(私)⇨青い靴ください.  (1回目の通信)  

サーバー(店員さん)⇨何センチの靴をお持ちしましょうか?   

pc(私)⇨青い靴の26cmをください。(2回目の通信)  

サーバー(店員さん)⇨かしこまりした

サーバーは2回目の通信(青い靴の26cmをください)を処理する際「前の通信(1回目の通信の青い靴ください)の内容を覚えていない」ので2回目通信する際1回目の内容を含めて伝えなければならない。このような通信(会話)をステートレスという.

なぜこのような通信にしたほうがいいのか?
⇨サーバーの負荷を抑えるため。ステートフル(会話を全部覚えている)な通信だとリクエスト数が増えるとサーバーが今までのリクエストの内容を覚えとく必要がありそれがサーバーに負荷がかかる。

統一インターフェース

⇨サーバーにリクエストを送る際以下のhttpメソッドのどれかを使用しリクエストを送るルール。要はサーバーに何して欲しいかを限定する

| HTTPメソッド | 操作                   | 説明                                                         |
|--------------|------------------------|--------------------------------------------------------------|
| GET          | 取得                   | リソースの取得を要求する。                                   |
| POST         | 作成                   | 新しいリソースを作成する。                                   |
| PUT          | 更新                   | 指定されたリソースを更新する。                               |
| DELETE       | 削除                   | 指定されたリソースを削除する。                               |
| HEAD         | ヘッダーの取得         | GETメソッドと同じリクエストを行い、ボディ部分を含まない。   |
| OPTIONS      | オプションの取得       | サポートされているメソッドやリソースに関する情報を取得する。 |
| PATCH        | 部分的な更新           | リソースの一部を更新する。                                   |
| TRACE        | トレース               | リクエストを受信したサーバーによって、リクエストを反映する。 |
| CONNECT      | 接続                   | プロキシを通じて接続を確立する。                             |

キャッシュ

⇨一度見たWebページをブラウザに一定期間保存しておく仕組み(要は毎回毎回サーバーにリクエストを送らない)

メリット.

  1. サーバーに負荷がかからない

  2. Webページを高速で表示できる

階層型構造

→サーバーに負荷をかけない(負荷分散)仕組みかつサーバーが落ちてもサービスを止めない仕組み

通常アプリを作成し利用しようとすると以下のように複数のサーバーを使用する必要がある

このサーバー構成の問題点は

  • クライアントが増えた時1台のサーバーに負荷が集中する(サーバーが落ちる=アプリが落ちる).

  • もし原因不明でwebサーバーが落ちたらアプリは使用不可能になる。

しかし.
以下のように同じ役割の複数のサーバー(階層化)を使用することで、1つのサーバーが落ちても代わりとなるサーバーで対応可能なのでサービスが継続して使用可能になる

コードオンデマンド

⇨クライアント側で特定の操作が発生した際に、サーバーから実行可能なコード(通常はJavaScriptファイル)をダウンロードして実行する仕組み

crud操作のurlとhttpメソッド

Action URL Http Method
Retrieve /movies/{id} GET
Create /movies POST
Update /movies/{id} PUT
Delete /movies/{id} DELETE