RESTful API とは何なのかについての、RESTful APIとは何なのか という記事に対して、WebAPI含めて自分の理解を確認するために書いている。
RESTful APIとは
RESTの原則に則って構築されたWebシステムのHTTPでの呼び出しインターフェースのこと。
以上を雰囲気で理解して割とそのままにしてきたひとはいるだろうか。私だ。
そんなの常識だろという方は、先に最後の「RESTfulのful とは」、「RESTとRESTfulの違いとは」について見ていただいてそれでも「ふーん」であれば、ブラウザバックしましょう、そういうレベル感の記事です。
REST
REpresentational State Transferの略
Representation は 表現 などの意。State = 状態。Transfer = 転送。
表現とは、Webサーバの送信するリソースの形式。
リソースとは、Web上に存在する情報、データのこと。
RESTとは、Webサーバと、Web上に存在する情報、データの形式の、状態を、転送する 位の意味になりそう。
RESTの原則
主に以下の4つの原則から成る。
よくある、「頭文字4つでREST」とかいうやつではない。
1. アドレス可能性 (Addressability)
アドレス可能とは、提供する情報がURIを通して表現できること。全ての情報はURIで表現される一意なアドレスを持っている、ということ。
URIを通じてリソースを簡単に指し示せる性質であるということ。
URIとは
URL と URI の違い
Uniform Resource Identifier 統一 資源 識別子 には
- Uniform Resource Locator 統一 資源 位置指定子
- Uniform Resource Name 統一 資源 名
がある。この2つはいずれもURI。
つまり「アドレス可能である」という変な日本語は、 統一 資源 識別子によって、一意になり、Web上に存在するデータを、簡単に示す（＝アドレスできる）ことができる、ということ。
エンドポイントとエントリポイント
エンドポイント：サービスを利用する側の視点
そのURLにアクセスさえすれば、それ以上何もしなくてもいい（APIに任せる）ので、エンド="終点"
エントリポイント：サービスを提供する側の視点
URLにアクセスがあることでAPIサービスの処理が開始されるので、エントリ=”入り口”
例えば自分の作ったシステムからgoogleのAPIを使うとしたら、GoogleのAPIのURLは自分にとってのエンドポイント。Googleから見たそのURLは処理が始まるポイント。だからエントリポイントになる。
2. ステートレス性 (Stateless)
ステートレスとステートフルって結局どう違うの？
これは有名なハンバーガー屋のやり取りの例。
客：ハンバーガーください。
店：ハンバーガーですね、ドリンクはいかがしましょうか？
客：ハンバーガーとコーラください。
店：ハンバーガーとコーラですね、サイドはいかがしましょうか？
客：ハンバーガーとコーラとポテトください。
店：ハンバーガーとコーラとポテトですね
(以下略)
以上ステートレス。
客：ハンバーガーください。
店：ハンバーガーですね、ドリンクはいかがしましょうか？
客：コーラください。
店：コーラですね、サイドはいかがしましょうか？
客：ポテトください。
店：ポテトですね
(以下略)
以上がステートフル。
で、RESTfulはHTTPをベースにした「ステートレス」なクライアント/サーバプロトコルであること。つまりセッション等の状態管理をせず、やり取りされる情報がそれ自体で完結して解釈できること。
「ハンバーガーとコーラとポテトください現金で」なこと。
3. 接続性 (Connectability)
情報の内部に、別の情報や(その情報の別の)状態へのリンクを含めることができること。
リソースに、別のリソースへのリンクを含めることができること。
リソースに含まれるリンクをもとに別のリソースに接続可能となること。
リソース、くどいが、
Web上に存在する情報、データ。それに含まれるリンクをもとに、別の「Web上に存在する情報、データ」に接続可能となること、ということ。
4. 統一インターフェース (Uniform Interface)
4つ目。情報の操作 (取得、作成、更新、削除) は全てHTTPメソッド (GET、POST、PUT、DELETE) を利用する。
GETとPOSTの違いについて
GETはURLに直接付加するので目でパラメータを見ることができる。
POSTはBodyに含めることが可能で目に見えない形での送信ができる。
CRUD と対比される。HTTPメソッドのうちGET、POST、PUT、DELETEは「CRUD」、つまり Create/Read/Update/Delete を満たす。
WebAPIとRest(ful)API
WebAPIの種類として
- XML-RPC
- SOAP
- REST
がある。念のためWebAPIとは
「厳格な定義はないが、広義にはHTTPプロトコルを用いてネットワーク越しに呼び出すアプリケーション間、システム間のインターフェース」。更に念のため、APIは、Application Programming Interface。
API実例：郵便番号API
WebAPIのサポート
自分にとって身近なので、ここに書いておく。
メーカーはいかにしてWebAPIのテクニカルサポートを行うべきか？ 等議論あり。
RESTfulのful とは
4原則と超基本がわかったところで最後に、これはどこにも書いてなかったオマケ。
RESTful API、REST APIと呼び方があるが、広義ではほぼ同じと考えて問題ない。
とあるが、それでも気になる ful とはいったい何なのか。
以下に答えを発見した。
What does the “ful” in RESTful mean?
https://stackoverflow.com/questions/50047879/what-does-the-ful-in-restful-mean
What's the difference between REST & RESTful
https://stackoverflow.com/questions/1568834/whats-the-difference-between-rest-restful
Representational state transfer (REST) is a style of software architecture. As described in a dissertation by Roy Fielding, REST is an "architectural style" that basically exploits the existing technology and protocols of the Web.
RESTful is typically used to refer to web services implementing such an architecture.
ざっくり：
REST（Representational State Transfer）は、ソフトウェアアーキテクチャのスタイルの一つ。ロイ・フィールディングの論文で述べられているように、RESTは基本的にWebの既存の技術とプロトコルを利用した「アーキテクチャスタイル」です。
RESTfulは、通常、そのようなアーキテクチャを実装したWebサービス、という意味で使用されます。
つまり
So REST is the architecture and RESTful an adjective?
→ RESTはアーキテクチャで、RESTfulは形容詞。RESTなアーキテクチャ性があること、これすなわち、RESTful。
Beautyは美で Beautiful は美しい。あ、そういう感じね～！つまりRESTful APIは「REST的な、REST性なAPI」、REST APIは「REST（というアーキテクチャの）API」ということで、結局雰囲気を理解した。スッキリしていただけたら幸いです。