こんにちは、やぎにいです。 やぎすけ Advent Calendar 2016の20日目です。
ついに2X日になってしまいました、今日を含めてアドベントカレンダーはあと5日。気合い入れていきましょう。

昨日は僕がCircleCIを使って、Middlemanで作ったものをrsyncでデプロイするを書きました。
昨日の記事もこの自動デプロイで記事が追加されたのですが、自分の想像以上に楽ちん（pushすれば記事が公開されるのが素晴らしい）でひっくりかえりました。

今日は今更ですがREST(ful)とはなんぞやというのを自分の理解を深める意味でもおさらいします。

はじめに

なんで今さらREST(ful)をおさらいするのかというと、このアドベントカレンダーをやろうと思った1つの要因でもある、Rails5でAPIサーバを作ってみるというのをやるからです。
ネタバレすると明日から数日はこのRails5でAPIをつくってみるという内容でアドベントカレンダーをやりたいと思っているので、その第0章という感じです。

今のうちに言っておくとここでRESTをおさらいしたからと言って明日からの記事で作っていくAPIは完全にREST準拠とは限りません、 RailsでのURLルーティングはMVCでRESTfulアプリケーションが作りやすくなっているので、もしRESTfulAPIにする時にもそういえばREST準拠とはってああだったなと思えるようにおさらいします。

RESTとは

そもそもRESTとはなんぞやという話です。
RESTとは、REpresentational State Transfeの略で2000年に提唱されている設計原則や考え方のことらしいです。

その原則というのは以下の4つから成ります。

• アドレス可能性
• 統一されたインターフェース
• ステートレス性
• 接続性

この4つのようです。

アドレス可能性とは

そのアプリケーションが提供する情報はURIを通して一意に表現できること。つまり、すべての情報はURIで表現することができるということ。
リソースはユニークアドレスを持つということですね。

統一されたインターフェースとは

リソースの操作に対して、全てHTTPのメソッドを利用するということです。
中でも重要なのは”GET","POST","PUT","DELETE"がHTTPメソッドで存在しこれらになります。
リソースを得るときはGET、登録でPOST、更新でPUT、削除でDELETEを使用することで統一と認識のしやすさを図ることが出来ます。

ステートレス性とは

状態を持たない（ステートレス）ということで、やりとりされる情報はその情報自体で完結するということです。
よく見る例はファストフードの注文で、

• ステートレスじゃないファストフード店
  店員「注文をどうぞ」
  客「Aセット」
  店員「飲み物はどうしますか」
  客「コーラ」
  店員「付け合せはどうしますか」
  客「ポテト」

• ステートレスなファストフード店
  店員「注文をどうぞ」
  客「Aセット」
  店員「飲み物はどうしますか」
  客「Aセットでコーラ」
  店員「付け合せはどうしますか」
  客「Aセットでコーラとポテト」

というのがよくみるたとえです。
両者の違いは、ステートレスではない方は店員が客の注文情報を記憶して捌いているわけですが、後者のステートレスなファストフード店では客の情報ですべてが完結しています。

接続性とは

情報の内部に別の情報や、その情報の別の状態へのリンクを含めること。
こうすることによってとあるRESTなりソースから他のRESTリソースを参照する場合は特別な機能を使うわけではなく、単にリンクをたどるだけでよくなるわけです。

これらを使うメリットは？

アドレス可読性によりURIにルールができることから、それを使う人や作る人はURIかリソースが何なのかがわかりやすくなったりする。
HTTPメソッドのGETでリソースの取得ができることで、ブラウザのアドレスバーにURIを入力すればリソースが手軽に参照できる。
ステートレスな実装をすることにより、負荷に応じたスケーラビリティが上がる。（これがどうやら一番のメリット）
インターフェースを統一することで、シンプルかつ一貫性のある標準化をすることができる。

といったものがRESTを採用する上でのメリットになるみたいです。

特にステートレスはそうで、上のファストフード店の例を出すと、情報を店員が保つ場合は店舗が混んできたときでも同じ店員でないと注文がわからなくなります。が、ステートレスだと別の店員でも対応できるので店員を増やしたとしても誰でも対応できるようになります。
この店員と客をサーバとクライアントと考えると確かにかなりスケーラビリティが向上しそうですね。

RESTfulとは

RESTfulとはつまり、このRESTの原則に則って構築されたものである。ということです。

ここで振り返るとRESTfulAPIってよく聞きますが、大体がなんかXMLを返すだけでちっともRESTじゃないものがこの世の中に多い気がしますね。
あとはXMLのレスポンスを返すものがRESTであるという認識もつよい気がします。
もちろんRESTではXMLでもjsonでもレスポンスの形式はいいわけで、最近はTwitterとかもそうですがjsonが多い印象です。（通信量的にも良さそう）

かという僕もRESTなAPIです！！とか言うのを見たときに「RESTってなんなんだ？XMLで返ってくるやつ？いやだなー」的な印象があったので改めて認識を改めることができました。

おわりに

今回はRESTとはという形でまとめました。
もちろん利点として上げたステートレス等にもデメリットはあり、今回は特に他の考え方と比較をしませんでしたが様々な考えがあります。

個人的にはRESTは使えるものは使うし、シンプルな設計だから人間にも計算機にも優しいなという印象があります。

つまり、RESTというのは上の原則とかの考え方であり、それを守ったものがRESTfulなものであるということでした。

明日からのRails5でつくるAPIもなるべくRESTな思考に沿って頑張りたいと思います。

以上、やぎにいでした。

Tweet      
comments powered by Disqus

---

<< Ruby on RailsでつくるAPI（導入編）　　　　　CircleCIを使って、Middlemanで作ったものをrsyncでデプロイする >>

---

---

2018やぎ小屋