Torihaji's Growth Diary

Little by little, no hurry.

初心者がREST APIを爆速で理解した(かもしれない)話

はじめに

みなさん、こんにちは torihaziです。

先週のSQL大激闘を乗り越え、次は APIと戦っています。

今回はそのAPIの中でも REST というルールに基づいて作られている API

REST API について つらつらしていこうと思います。

それでは ltg

あ、ちなみに APIって言葉はググってから進んでくださいね。

自分もググって分かったので大丈夫です

RESTってなに

堅苦しい日本語の定義です。

分散型ハイパーメディアシステムの設計原則群

1つづつ紐解きます。

分散型

システムやデータが複数のコンポーネント(コンピュータなど)に分散されて配置されている状態のこと

これにより1人で対応しきれないたくさんのデータを処理できるようになります。

100の作業量はスーパーな1人よりノーマルな100人でやった方が仕事分散できますよね。

対義語としては中央集権型です。

ハイパーメディアシステム

テキスト、画像、音声、動画を組み合わせたメディア要素をリンクによって結合させているようなシステムのことです。

昨今のWebそのものと認識して良いと思います。

設計原則群

要はルールのことです。決まり事。作り方と言ってもいいです。

以上を総括すると、

下図のようないろいろ繋がってるシステムの綺麗な作り方

というイメージになります。

REST APIとは

では本題のREST APIについて。

上記の説明を元に説明すると

なんか決まったルールで作られた WebAPIの1つ

です。

WEB API とは 情報のやり取りに HTTPというプロトコルを使用する APIのことです。

ということなので改めて翻訳すると

なんか決まったルールで作られ、情報のやり取りにHTTPを使用する API

ということになります。

RESTのルール

ここからはそのなんか決まったルールについてです。

RESTルールを満たすには下記の6箇条が必要です。

1つ クライアントサーバ型アーキテクチャであるべし
1つ 通信はステートレスであるべし
1つ 情報をキャッシュできるようにするべし
1つ インターフェースを統一すべし
1つ 階層化システムであるべし
1つ リソース指向であるべし

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

クライアントとサーバがいて、それぞれ役割が分かれているシステムであることということです。

「情報を欲しい!」というクライアントと「情報をあげる!」というサーバがいます。

アーキテクチャは難しく捉えがちですが、作りや建築学でいう建築様式のような意味合いです。

ちなみに役割が同等のもので構成されているようなシステムを「P2P(ピアツーピア)」と言います。

LINEがこのシステムだった(はずです)

ステートレス通信

状態を持たない通信のことです。

これについては色々な例え話で説明されていますね。

個人的には今さっき思いついた例がしっくりきたのでご紹介します。

お店にて、「大将!! いつもの!!

と言って

はいよ!! とくればステートフル

は? とくればステートレス

です。

何が違うかというと お客さんのいつものというものを大将側が覚えているか否かです。

これにはそれぞれ次のような利点欠点が存在します。

ステートフル
利点

伝える側(クライアント)が提供する情報量が少なくて済む。

欠点

もらう側(サーバ)が以前の情報を覚えておかなければならない。

ステートレス
利点

もらう側(サーバ)が以前の情報を覚えておかずに済む

欠点

伝える側(クライアント)側が毎回いつもの!!の詳細な内容を伝えないとダメ

(生1つに枝豆に鶏皮につくねにネギまに。。。。という感じで)

どちらがいい悪いという問題ではなく、用途によって選びましょうということです。

キャッシュできる

キャッシュというのはサーバ側からもらった情報をクライアントが覚えておくことです。

何がいいかというと、情報通信量の削減です。

前にもらった情報を覚えているので、毎度毎度全部を要求する必要がありません。

ただもらった情報の中でもいらない情報をキャッシュする必要はないので

必要なもののみキャッシュすることが必要です。

インターフェースの統一

特徴としては以下の4つです。

  • 情報(リソース)はURIという一意の識別子で表すことができる
  • リクエストやレスポンスを読めば情報の意味がわかる
  • システム内のリソースを全て同じ方法で参照できる
  • HATEOSであるべき

この最後のHATEOSについて少し説明します。

HATEOSとは レスポンスの中に他データのURI等をリンクとして含めることで

そのデータを見れば次にどのURIにアクセスをすれば良いかわかるような設計概念のことです。

例えばWebサイトを試しに開くと、色々なリンクがありますよね。

お困りの方はこちら!のリンクをクリックしたら問い合わせページに飛ぶだろと推測できますよね。

APIのレスポンスにも同じようなリンクデータを含めるわけです。

階層化システム

複数の階層に分けたコンポーネントによって情報を段階的に処理するようなシステムのことです。

それぞれ役割が決まっていて、独立していることが特徴です。

リソース指向

システム内のすべての情報はリソースとして扱います。

そしてそれらをURIで表現するべきであるという考えのことです。

終わりに

いかがだったでしょうか。

REST APIについてふんわりとでも理解することはできたでしょうか。

私の理解としては

REST API

REST という設計ルールに従い、情報のやり取りにHTTPプロトコルを使用するAPI

と理解しています。

みなさんはどのように理解しましたか?

初めて読んだ時は何だか腹落ちしなかったにも関わらず

今読み返してみるとわかったような気がする

という状態になってくれたら嬉しいです。

ネットをググれば色々な定義が載っていて

どれが正解なのかわからない、なんてこともあるかと思います。

個人的にIT用語は辞書的な意味を覚えてもほぼ無意味だと思うので

まずは自分の中で定義を確立させてから

そこから色々な文献や他者の意見を読み聞きして

自分なりの理解を確立させていったほうがいいかと思います。

上達には逃げずに自分の言葉で言語化!これにつきます。

頑張ってください。

僕も負けじと頑張ります。