RESTとは

最近Web系を学んでいると、目にすることが多くなった『REST』ですが、これまでは『休憩？残り？』とかイメージしていましたが、ようやく出会えました😄

と、そんなことは置いておいて、『REST：REpresentational State Transfer』の略で、Webサービスの設計モデルとのこと。

・・・設計モデルと聞いてもピンとこなかったですが、

RESTは設計に際し以下を設計原則とするよう提言されています。

アドレス指定可能なURIで公開されていること

インターフェース(HTTPメソッドの利用)の統一がされていること

ステートレスであること

処理結果がHTTPステータスコードで通知されること

参考：RESTの設計原則であるRESTful

を読んで、ようやく腹落ちしました。上記のようなことを守るように設計されたWebサービスということなので、自分がよく使う一般的なWebサービスのことを指しているんだと分かりました。

ここで、『REST以外ってどんなの🤔』となったので少し情報収集。

どうやら『SOAP：Simple Object Access Protocol』があり、RESTもSOAPも、オンラインデータ送信に対するアプローチ方法らしい。

大きな違いとしては、SOAPはプロトコルであるが、RESTはプロトコルではなくアーキテクチャ原則ということ。これが意味するところは、SOAPは厳格に組み込むための設計をしなくちゃいけないが、RESTはアーキテクチャのガイドラインに沿っていれば、柔軟に実装を提供して良い。

上記のようなプロトコルとガイドラインという違いからも、SOAPは多くのエンタープライズのニーズに合わせた組み込みのセキュリティとトランザクション・コンプライアンスを提供するけれど、処理が重くなりやすい。REST APIは軽量で、IoT (モノのインターネット)、モバイル・アプリケーション開発、サーバーレス・コンピューティングなどの先進的なコンテキストに適しているらしい。(参考：REST とSOAP)

脱線したが、RESTのアーキテクチャを守ったWebサービスがAPIを公開していると、それら公開サービスからデータを取得できるようになる。取得データを用いて、自分のシステムと組み合わせ新たなサービスを作成できるというのもRESTの魅力らしい。

RESTの特徴

クライアント、サーバー、およびリソースで構成されるクライアントサーバー・アーキテクチャ
クライアントとサーバー間の通信がステートレスであること

サーバーにクライアントのコンテンツが要求をまたいで保存されることはなく、セッション状態に関する情報はサーバーではなくクライアントが保持する。
クライアントとサーバー間のやりとりの一部を不要にするためのキャッシュ可能なデータ
コンポーネント間で統一されたインタフェース

アプリケーションのニーズに固有の形式ではなく、標準化された形式で情報が転送される。
階層化されたシステム制約

クライアントとサーバー間のやりとりは、階層レイヤーによって仲介可能
オンデマンドのコード

サーバーは、実行可能なコードを転送することでクライアントの機能を拡張可能 (ただし可視性が低下するため、このガイドラインの準拠は必須ではない)。