私は普段、Androidアプリの開発業務に携わっています。
とある日の業務で、サーバサイドの調査を行う機会がありました。
そこで理解が浅いと感じ、今回は調べてみたことをまとめてみました。
いっしょに基礎から、
１つずつ理解していきましょう！
RESTとは
RESTは、英語で「REpresentational State Transfer」と書きます。
日本語に訳すると「代表的な情報転送」という意味になります。
要するに、デファクトスタンダード（広く普及した）となったWebインフラを活用して、Webサービスに簡単にアクセス可能にする仕組みのことです。
仕様ではなく、WebAPIの仕様を決めていく中で基本となる考え方（概念）にあたるので要注意。
RESTの設計思想
下記の4つの設計思想（考え方）で作られたインターフェースを「REST API」と呼びます。
HTTPリクエストを受け付けるインターフェースとなります。
Stateless
ステートレス。つまり、状態を持たない(維持しない)ことを意味します。
セッションなどの情報管理を行わず、通信の情報は単体で完結します。
要するに、個々のHTTPリクエストが完全に分離しているということです。
ステートレスとは、処理に必要な情報を一度に詰め込んでリクエストを投げることです。
自己完結型なタイプですね。
こういうタイプの人って、
ちょっと気難しくて苦手なのよね。
ちょっ、主観を言わないの！
とはいえ、実社会では『ステートフル』な人の方がコミュニケーション取りやすいです。
以下のように、会話に近いやり取りがステートフルと呼べます。
前の情報（ステート・状態）を保持したまま会話（通信）が進んでいますね。
ここで、それぞれのメリットとデメリットを整理しておきましょう。
- ステートレス🧊
- メリット
- 一度にリクエストの内容を受け取れるため、クライアントの状態を気にしなくていい。
- 言い換えると、常にデータ操作に必要なデータが揃っている状態になる
- デメリット
- 不要なデータが乗っかる場面もあるため、冗長になるケースがある。
- 一度にリクエストパラメータを受け取るため、どこの値でエラーが起きたのかなど解析が難しいことがある
- メリット
- ステートフル🔥
- メリット
- やり取りが簡潔なので、ネットワーク帯域の節約になる
- デメリット
- クライアントの状態(ステート)を把握しておかなければならないため、サーバ負荷が増えがち。
- システム拡張する際、サーバを増設したらクライアントの状態(ステート)を同期しなければならない。
- メリット
どちらも一長一短ですが、REST APIにおいてはステートレスが採用されているのでご注意ください。
Uniform Interface
「均一なインターフェース」という意味です。
情報の操作は、HTTPメソッドで指定して実行します。
- 取得（GET）
- 作成（POST）
- 更新（PUT）
- 削除（DELETE）
データベースの操作「CRUD」と対比されることが多いです。
※厳密にはPOSTはCRUDに対応していません。
Addressability
「アドレス指定能力」という意味の言葉です。
全てのデータやリソースは、識別するための一意のURL定義を持っています。
アドレス指定可能なURIで公開されているということですね。
提供する全ての情報は、URIで表現される一意（１つしかない）なアドレスを保持します。
以下は、ウェザーニュースのAPIのひとつ。
こんな感じに、アドレス指定することができることを「Addressability」といいます。
Connectability
「接続性」という意味です。
アプリケーションの「情報」と「状態遷移」の両方を扱えます。
単純に、あるリソースから他のリソースへのリンクを含めることができます。
まとめ
REST は以下のような決まり事から成り立っていることがわかりました。
- Stateless
- Uniform Interface
- Addressability
- Connectability
機能ではなく、概念なので様々な言語に適合することができます。
この概念を理解した上で、APIの作成を進めていけばRESTfullな設計ができるはずです。
参考文献
