2012年にpyconjpなどでFlaskを知ってマイクロフレームワークだし小さなサービス作るぐらいには使えそうって良さ気な印象をもった。
それからしばらくして、RDBを使ってREST APIを作る話があったんだがそれにFlaskを使って苦労・失敗したって感想を書いていく。
-
MethodViewクラスが使いやすい
エントリポイントごとにMethodViewクラスを継承したクラスを作成して get/post/put/deleteメソッドを定義するとそれぞれGET/POST/PUT/DELETEリクエストに対応出来るのでREST APIを作るのはほんとうに簡単だった。 -
リソース更新のためにPOSTを使わない
API利用者のために更新もPOSTで受け付ける仕様にしたんだが実装始めた段階でやっぱり面倒くさいなって思ってしまった。
SQLAlchemyをORMな使い方してうまくやるにはこの方式はあんまり向いていなかった。
REAST APIはPOST/PUT/DELETE/GETで作るようにすれば開発者も利用者も幸せになれるでしょう。 -
Flask-SQLAlchemyが使いにくい。
Flask-SQLAlchemyについてもあんまり参考になるような利用例がなくてサンプル以上の使い方をするのが難しい。素のSQLAlchemyを使ったほうが柔軟性が高いし他のバッチ処理とかでもコードを流用できるので拡張はなるべく使わないほうがあとあとウレシイんじゃないかな。 -
Blueprintのドキュメントがあんまり無い
しばらくしてコードが成長してくると1つのスクリプトでは大きすぎるように感じてBlueprintというコードを分割するモジュールを使いたくなるんだがこれもドキュメントが無くてどうやって使っていいのかコード読んだりして使えるようになるまで手間と時間がかかる。オレはBlueprint使った分割をあきらめて1ファイルに無理矢理収めてしまった。 -
テストのやりかたがわかりにくい
3,4,5 に関しては全般的にドキュメント/サンプルコードが少ないってことに帰結すると思う。Flaskはまだまだ利用例が少ないからこれからこの辺りのセクションの情報量が増えることに期待したい。 -
DELETリクエストでパラメータを受けとれない
実装をはじめるまで気づかなかったので削除するタイミングでリソースを変更する仕様を採用しているとあとで困ることになるので知っておいて欲しい。
追記
ちゃんと、下のようなDELETEリクエストでrequest.args["hoge"]でパラメータ取れました。
% curl -X DELETE "http://localhost:9999/users/100?hoge=100"
SQLAlchemyに関してはちょっと利用したことがあるだけの知識で使ってみたので的が外れてたかもしれない。初心者でFlask + SQLAlchemy で何か作るってときにはハマるかもしれないので書いておいた。
2012年はFlaskを使っていろいろ経験できたので、2013年はFlaskよりも機能が充実したDjangoを使って新しい経験を増やしてみようと思います。
今年もよろしくおねがいします。
Amazon.co.jp： Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus): 山本 陽平: 本
PyCon JP 2012 hands-on セッション/ FlaskによるWebアプリケーションの実装とプログラミングツール