はじめに
「REST API」と「Push技術」どちらもWeb業界で頻繁に耳にするキーワードです。
それぞれの技術を提供するサービスやパッケージも増えてきており、これから更に進化していく技術です。
しかし、いくつかのWebページでは「REST API リファレンスガイド」などの中に「Push通知」というような項目があり、少し違和感を感じています。
なぜなら、REST の思想と Push通知の思想は相反するものと考えるためです。
なぜそう考えるのか、詳しく説明いたします。
元々の「REST」提唱者が論文で定義をあいまいに記載しているため、このような解釈の違いが生まれるわけですけどね(笑)
そもそも RESTful とは?
以下に REST についてまとめた記事がありますので、合わせてお読みください。
こちらもCHECK
-
-
REST(Representational State Transfer)とは?【基礎知識】
Webサービスなどでよく耳にするRESTとは、どんなものなのでしょうか。RESTとRESTfulの定義や、RESTfulと呼ばれるための4つの原則、原則に沿って設計した場合のメリット・デメリット、インターフェイスを考える手順をまとめています。
続きを見る
RESTのポイント
後に解説していきますが、ロイ・フィールディングがネットワーク設計モデルについて書いた2000年の博士論文で初めて登場した Web サービスの設計モデル(ガイドライン)です。REST の設計モデルに基づいて提供されるものを RESTful と言います。
Push通知とは?
以下に Push 通知に関する Push技術 の記事がありますので、合わせてお読みください。
こちらもCHECK
-
-
HTTPサーバーからPushする技術の進化【まとめ】
HTTP1.xが登場して以来、様々なプロトコルが誕生しました。LINEやTwitter、Facebookなどで使用されているサーバーからクライアントにデータを送信する「Push技術」も発展した。本記事はPush技術の進歩・歴史をまとめています。
続きを見る
Push技術のポイント
簡単に言うと、クライアント側から明確な GET 要求がなくても、サーバー側で発生したイベントをクライアントに伝える仕組みです。クライアントがデータを GET する代わりに、サーバーから即座に通知することです。
REST と Push通知の思想が相反すると考える理由
それでは「相反する思想」と考える理由をRESTが登場した論文を引用しながら説明します。
その①:RESTはPull型が原則
論文「5.4 Related Work」では、以下のような記述があります。
In the REST style, consuming components usually pull representations.
引用:https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
また、「5.1.2 Client-Server」ではクライアント-サーバーの思想を謳っています。
The first constraints added to our hybrid style are those of the client-server architectural style.
引用:https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
つまり、RESTはクライアントがサーバーからリソースを取得するモデルが原則と言えます。
対して、Push通知は、サーバーから情報を通知することを指します。
通信の起点が全くの逆になっているため、Push通知とは相反する思想と言えます。
その②:RESTはインターフェスの統一が原則
論文「5.1.5 Uniform Interface」では、以下のような記述があります。
The central feature that distinguishes the REST architectural style from other network-based styles is its emphasis on a uniform interface between components.
引用:https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
一般的に、REST を利用した通信は以下のようにインターフェイスの統一を行います。
- リソースの操作は HTTP Method (GET, POST, PUT, DELETE)を使う
- リソース操作の結果は、HTTP Status Code を使って表現する
HTTP Method は HTTP Request 用のものであって、クライアントから発行します。
また、サーバー側からは HTTP Response で Status Code を返すインターフェイスです。
HTTP Request が起点となるインターフェイスのため、Push通知とは相反する思想と言えます。
スポンサーリンク
その③:RESTはステートレスが原則
論文「5.1.3 Stateless」では、以下のような記述があります。
Session state is therefore kept entirely on the client.
引用:https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
セッションの状態は、サーバーでは保存しないことが原則となっています。
一方、Push通知を行うには、サーバーが送信先を覚えておかなければなりません。
Push通知では、サーバーがセッション情報を記憶する必要があるため、相反します。
結論:RESTとPush通知は思想が合わない
ここまでで、REST と Push通知の思想の違いは理解いただけたと思います。
どちらもバズッたワードですので、Webサービスの商品宣伝や顧客要件などでも同時に使われることが多いと思います。
例えば、あるリソースのモニターを REST API で開始し、リソースに変化があればサーバー側から Push通知してもらうというインターフェイスがよくあります。
インターフェイスは REST API であるが、RESTful なサービスではない。ということです。
つまり、結論としては「REST と Push通知は相反する思想」と言えそうです。