hagoack20

WM API

Sinatra で WM の DB をラップして、 RESTful web API を提供する。

使用したフレームワーク/ライブラリについて

Sinatra は軽量の Ruby web フレームワーク。 メソッドと URL との紐付けが簡単に行える。

URL に対する基本的な 4 つの HTTP メソッド (GET, POST, PUT, DELETE) に対応。 大抵のブラウザは GET/POST のみ対応している。 DELETE とかまでサポートしているクライアントは少ない。 curl だと対応していたはず。

今回の API は画面をもっているアプリケーションサイドのことではなく、 プログラム API の話。

容易なデータベースアクセスを実現するために、 Ruby のデータベースアクセスライブラリ Sequel (O/R マッパー) を利用。

データベースへ接続することや、レコードのオブジェクトマッピングが簡単に行える。 様々なデータベースに対応している。

今回は WM の一部の機能を API 化した。

REST について

REST については RESTful web サービス という本を参考にした。 REST はリソース指向アーキテクチャ。

例えば、 フリッカー の URI にはメソッド情報が URI パラメータとして含まれている。 プリッカーは、 パラメータとして受け取ったメソッド情報に基づいて コンテンツ (リソース) を提供、更新、追加、削除する。

REST の考えでは、 URL はリソース情報の場所のみを表すべきで、 そのリソースに対する操作は HTTP メソッドで表す。 HTTP メソッドは GET, POST, PUT, DELETE。

API が乱立したとき、 URI にメソッド情報が含まれていると、 API の全体把握が難しくなる。 REST だと URI の対するメソッドは 4 種類だけなので、 切り口も統一され API の全体把握が容易になる。

ある RESTful なアプリケーションとはこうあるべきだ、という説明があった。

メソッドを実行したあとの戻り値をどうするべきかという話。 件の本によると HTTP ステータスに従ってエラーの種類を表現し、 エラーの説明を BODY で表現すると説明されていたと思う。

リソースの場所を表す URL について。 例えば、以下の URL について、

/schedules/<username>/<YYYY>/<MM>/<DD>

これは username が先頭であってもいいのかという話。

なにか、明確な指針ってないのだろうか。 Rails には routes.rb があり、その記述によって URL が決定される。 件の本に何かいい例は紹介されていないか。 提供するサービスや API の使われ方によって URL の設計が変化するだろう。 URL の設計についても、なんらかのパターンやベストプラクティスがきっとある。

勉強会スタイル：議事録について

以降の勉強会では、参加者の ツイッター 書き込みを議事録としていきたい。

議事録と通常書き込みを分類するために ツイッター のタグ機能を使う。 使用するタグは #hagoack<n> - n は勉強会回数

例：

• はじまるよ #hagoack20

勉強会スタイル：ネタ帳、勉強会の振り返りについて

ネタ収集にも ツイッター を活用していきたい。使用するタグは #hagoack

例：

• lisp.c - http://nakkaya.com/2010/08/24/a-micro-manual-for-lisp-implemented-in-c/ #hagoack

KPT で勉強会の振り返りを行っていきたい。 (OJAG で KPT を用いた勉強会の振り返りを行っていた)

KPT についてはこちら http://www.atmarkit.co.jp/aig/04biz/kpt.html

KPT についても ツイッター を活用。 使用するタグは #hagoackK, #hagoackP, #hagoackT (大文字小文字区別なし)

例：

• LC 枠とってもいい感じ #hagoackK
• 1h ごとに休憩をいれた方がいいかもしれない #hagoackP
• ハンズオンやってみたい #hagoackT

勉強会スタイル：勉強会のまとめを社外へ公開

Github wiki を使う。

理由：ウェブブラウザから書き込むことが可能かつ org-mode フォーマットに対応