API仕様の重要性とAPI-Firstな開発手法の導入について(2/3)

前回の記事はこちら
[API仕様の重要性とAPI-Firstな開発手法の導入について(1/3)](http://qiita.com/maximum80/items/b382ef0c3bbe2fa4e31a)

前回は、APIについての説明をしましたので、今回は**REST**という言葉の意味や内容についてまとめていきたいと思います。

##REST APIとは
よくRESTとかRESTfulって言葉をよく聞きますが、まずはそれぞれの意味を詳しく調べてみました。
引用ですが簡単にまとめます。

###REST
>RESTはREpresentational State Transferの略。
RESTとは、2000年にRoy Fielding氏が提唱した、分散システムにおいて複数のソフトウェアを連携させるのに適した設計原則の集合。また、狭義には、それをWebに適用したソフトウェアの設計様式のこと。一般には後者の意味で用いられることがほとんどである。（引用元：eWords）

###RESTful
>「RESTfulな○○」という言葉は、「RESTの制約に従っている○○」という意味を表す。RESTとは、アーキテクチャ・スタイルの一種で、「制約の集まり」と考えてよいだろう。何を制約するか？ それは狭義では「どのようにHTTP通信を利用するか」を制約する。HTTPメッセージにはどのような情報を格納するか、どのようにHTTPメソッドやHTTPヘッダを指定するか、などといった制約の集まりがRESTである（引用元：atmarkit）

###REST(ful) API
>RESTful APIとは、Webシステムを外部から利用するためのプログラムの呼び出し規約（API）の種類の一つで、RESTと呼ばれる設計原則に従って策定されたもの。RESTそのものは適用範囲の広い抽象的なモデルだが、一般的にはRESTの考え方をWeb APIに適用したものをRESTful APIと呼んでいる。（引用元：eWords）

まとめるとRESTとは、**Webで管理するソフトウェアに適した設計様式**であり、RESTfulとは、その設計に従ってつくられる、という意味だそうです。調べたところによると、もともとはRESTという言葉のみだったのだそうですが、**なんちゃってRESTが横行**したそうで、RESTにきちんと従っているものをRESTfulとわざわざ表現するようになったのだとか。


##RESTの具体例
それぞれの言葉の意味は理解出来たとして、具体的にRESTの設計手法とはどのようなものなのかを調べてみました。

簡単に図でまとめると、
![Screen Shot 0027-06-07 at 7.31.13 PM.png](https://qiita-image-store.s3.amazonaws.com/0/6702/19c2b7db-e44a-2c40-2095-5a01acfcba79.png "Screen Shot 0027-06-07 at 7.31.13 PM.png")

に則って設計されているもののことだそうです。
ここで覚えておきたいのが、

* リソース(もの)に従っていること
* リソースはURI(識別子)を持つこと
* HTTPメソッドによって動作がおこなわれること
* HTTPリクエストには[ステータスコード](http://ja.wikipedia.org/wiki/HTTP%E3%82%B9%E3%83%86%E3%83%BC%E3%82%BF%E3%82%B9%E3%82%B3%E3%83%BC%E3%83%89)が伴うこと



という点です。細かな定義や正しいRESTの設計手法については

* [RESTなAPIとは何か](http://bokukoko.hatenablog.com/entry/2014/10/12/REST_%E3%81%AA_API_%E3%81%A8%E3%81%AF%E4%BD%95%E3%81%8B)
* [RESTのベストプラクティス](http://postd.cc/some-rest-best-practice/)

この辺りを参考にしてみてください。

##実際に確認してみよう
実際にブラウザ（今回はChrome）の以下の手順で、上記の具体的な内容を確認することが出来ます。

```
右クリック ＞ 要素の検証(Inspect Element) ＞　Networkタブを選択　＞　Headersを選択
```

すると、以下のような通信をおこなっていることがわかります。わかりやすくそれぞれ説明文を加えます。


![Screen Shot 0027-06-07 at 7.20.20 PM.png](https://qiita-image-store.s3.amazonaws.com/0/6702/bd827594-493e-9d97-fd5d-2eb387813c6c.png "Screen Shot 0027-06-07 at 7.20.20 PM.png")

上記はQiitaのTOPページにアクセスした時に表示されるもので

* 54.248.124.252というIPアドレスの80というポート番号に
* http://qiita.com というURLで
* GETリクエストを送信し
* 正しくGET出来ました

という意味を表します。
このようにいろんなWebサービスを利用するときに、どのようなリクエストがおこなわれているのかをチェックしてみると、Webサービスの仕組みを深く理解することが出来るかもしれません。

##RESTのメリット
1. わかりやすい
	* URIに規律があるため、みたら直ぐに何をしているのかがわかる
	* サービス内のリソースがURIで参照することが出来る
	* 参照URIでは、常に同じレスポンスが期待できる
- スケールや連携しやすい
	* 新たな機能などにも対応しやすい
	* RESTAPIを活用すればマッシュアップサービスがつくりやすい

という大きく2つのメリットが有るようです。（デメリットも有るようなのですが今回は触れません）

##参考になる実際に公開されているRESTful API一覧
国内外のIT企業では、有償あるいは無償にてAPIを公開しています。
REST APIを学ぶ上で非常に参考になるAPIを紹介します。

* [Github API](https://developer.github.com/v3/)
* [Google API](https://developers.google.com/apis-explorer/)　※沢山あるので注意
* [Facebook Graph API](https://developers.facebook.com/docs/graph-api)
* [Qiita API](https://qiita.com/api/v2/docs)

このように、様々な企業が公開しているREST APIを参照し、共通点を探したり異なる要素を探すことで、その設計手法を勉強するのも方法としては面白そうですね。

REST APIの内容や重要性が理解できたところで次回は具体的に、API-firstな開発手法のご紹介と実践を行っていきたいと思います。


## 今回参考にした記事など
* [第2回 RESTfulなAPIの設計を学ぼう](http://www.atmarkit.co.jp/ait/articles/1310/23/news078.html)
* [今さら聞けないWebAPIの実装方式RESTとSOAPの違い](http://qiita.com/pink/items/f1a22840619d3b79c4f2)
* [REST 【 REpresentational State Transfer 】 e-Words](http://e-words.jp/w/REST.html)
* [REST 入門(その3) 全てはリソースから](http://yohei-y.blogspot.jp/2005/04/rest-3.html)
* [REST(wikipedia)](http://ja.wikipedia.org/wiki/REST)