Welcom to WebAPI World
Introduction
- 本記事はHZ Colloquium Advent Calendar 2014の12/5分の記事です。
- 今日は過激に適当な話も入れながら WebAPI について書いていく。
- なお、お仕事で課題を見事に解決できず、明日死亡フラグがたっているなかでの執筆なため 全体的にテンションはおかしめ。
- Atom + middleman にて配信中。やっと静的サイトジェネレータの良さがわかってきたころあい。
Welcome to WebAPI World
これを書きながら Web2.0, Mashup などの言葉を思い出す（だいぶ昔の話なのか）。
それらを構成する要素にWebAPIってやつもあった。API (Application Programming Interface)です。
Webの技術をベースにしたAPIです。Webの技術ってなんでしょうか。それはHTTP(HTTPS)やURIのことです。
プロトコルのことです。
ここで思考をもっていってほしくない方向は「HTML = Web」って考え方です。Webページとかの延長線上の話としては
捉えないほうがよいと思います。いったん忘れましょう。
WebAPIといってもいくつか宗教があります。SOAP, WSDL, REST, RESTfulなどがそれです。
今はREST, RESTfulが全盛です。SOAPやWSDLは仕様が複雑すぎてはやらなかったらしいです。
このあたりの歴史は「Webを支える技術」に書いてます。Web関係のエンジニアはあれを読むべき。
「Web」の捉え方が少し変わるから。
REST(ful) WebAPIとは
REST(REpresentation State Transfer)の略です。アーキテクチャ（設計方法？設計原則？ととらえればよいのか） の名前です。RESTな方針に沿って設計されているシステムをRESTfulなシステムというらしい。 RESTを極めたものの証なのです。下記はRESTの特徴です。4つ書きます。もう少しあった気もします。
リソース
以下は全てリソースです。 * 大阪の天気 * 俺の明日の予定 * 飲み会の写真
リソースの識別子
全てのリソースは1つ以上の識別子を持ちます。「大阪の天気」だとこうなる。なるほど、識別子とか小難しいが RESTではURIでの指定になるんですね。
ちなみに1つ以上と書いたのは、上記は以下のURIでも同様だから（以下は仮ね）。つまり、同じ情報でも 捉え方は複数あるよということ。そのためにリソース自体が複数識別子で参照されることがありえる。
どうですか？なんだかセマンティックな話ですよね。セマンティックウェブ！です。ちょっと違うけどそそるでしょ？
統一的なインタフェース
RESTはHTTPの技術の上に成り立っています。ということはHTTPの技術をそのまま使います。HTTPって メソッドを持ってるって知っていましたか？実は自分は言われるまで意識していませんでした。 それは「GET」とか「POST」といわれているやつです。あと「PUT」「DELETE」があります。他にも いくつか（拡張含めるともう数種類あります。書きません） これってHTTPのメソッドなんですね。
class HTTP {
public GET() {
return hoge
}
public POST() {
return "200OK"
}
public PUT() {
return "404NotFound"
}
public DELETE() {
return "SUCCESS"
}
}
まぁすさまじく適当ですが、こんなイメージなんでしょうか。基本的にこのあたりのメソッドをメインに使っていくはずです。 RESTではHTTPのメソッドを使うことになっているので、それ以外のことを考慮する必要がないんですね。そういう意味では HTTPのメソッド（API）にのっとっているので統一的ってことですね。ちなみにブラウザでURLをたたくと GETメソッドでコンテンツをとりにいくという動きになります。
ステートレス
ステートレスの反対はステートフルです。どういう意味でしょうか。 * ステートレスはサーバ側で状態を管理しない。常にサーバとクライアントは疎 * ステートフルはサーバ側で状態管理をする。セッション維持とかcookieの話。
ステートレスにするとサーバとの接続維持が不要となるのでサーバリソースの解放に貢献できる。 が、認証が必要になる場合はステートレスなAPIだと毎回認証の処理が走ってかえってリソース食うか？ ちなみに tips レベルの話だが「認証」と「認可」の違いをご存じだろうか。
- 認証（Authentication）：本人確認（大概はIDとパスワードの対でご本人様であることを確認（認証）する。
- 認可（Authorization） ：リソースへのアクセス権限に沿ってアクセス制限をすること。
認証されたからといって全てのリソース（ウェブサイトとか）にアクセスできるわけではありません。 そこには、管理者しか見れない（管理者権限保持者のみ閲覧可）なページもあるわけですね。 認証で本人か確認し、認可でその人の持っている権限（ロール）に沿ってできることを制限するという考え方です。 脱線しました。脱線したついでに眠くなってきました。当然、この後RESTfulなWebAPIでなんぞやるんだろうな？って 話にはなるのですが、序盤の序盤までしか動かせなかったのでこうご期待にさせてください。
RESTfulなWebAPIの実装
最近はLAMP（Linux, Apache, MySQL, PHP）ではなくてMEAN（Mongodb, Express, AngularJS, NodeJS）らしいぜ。 ということでnodejsとexpressをインストールしてWebAPIもどきを動かしていました。次までにもうちょい発展させて 公開といきたいところです。ちなみにmongodbってスケーラブルな設計できるけどトランザクションとか機能としてないって 書いてた。配信専用？ある程度の枠組みだったらトランザクション、というか読み書きの順番は保障されるとか って話だからうまく使えばいいんだろうね。あと、HTTPSでロードバランサーかました可用性の高いいけいけなWebAPI 作りたかったけどAWSのELB(Elastic Load Balancer)高かった… NWトラフィック関係なく月4000円は固定で かかりそうな勢いだった。しかもSSL証明書はでふぉで使えるものあんのかなーって安易に考えてたら なかった。かわなあきまへんのか！そこまでやるー？うーん、SSL証明書のレベル低い奴は安いって書いてたけど どんなもんなんだろうなぁ。ELBじゃなくてもLinuxでロードバランスしてもいいのか（HAProxyだっけ？）。SSLはオレオレ 証明書は自己満なのでやりたくない。「https://api.codelogue.com/」とかでかっこよくキメタイ！ 思いとしては誰でもWebAPIでお望みの情報を配信できるぜ、WebAPI基盤を作りたい。誰得ー？
P.S. WebAPIだぜ！インタフェースだぜ！とはいっても配信するコンテンツが面白くていい感じじゃないと、ただの木枠 なんだぜ…