API 設計をやってみる

work

アルバイト

RESTful Web API の概念

そもそも API というのを開発したことがないので、まずは RESTful Web API の基礎概念を学習した。

Representational State Transfer - Wikipedia
Learn REST: A Tutorial
Trying: REST api design
A RESTful Web service, an example
http://www.freshblurbs.com/pragmatic-restful-api-design
http://www.stereoplex.com/blog/mobile-api-design-thinking-beyond-rest

これらのドキュメントから wikipedia:CRUD の考え方、API 設計と URL 設計の違い、リソースの考え方、バージョンと言語のパラメータ、サンプルをみてイメージを膨らませた。また最後の Mobile API Design の記事は、Nate Aune と Anna Callahan による valentun.es の講演について書かれたもので、ちょうど同じお話しを EuroPython 2011 で私も聞いていた。

Put another way, PUT is idempotent - if you do the same PUT twice (and there's no other state changes in between) then the system state will be the same. POST carries no such guarantee.

PUT は idempotent なんだという概念を知らなくて斬新だった。

API 設計

これも EuroPython2011 の基調講演から、一般論として API は階層化するのが良いというのを学んだ。そこで低レベル API と高レベル API を提供し、高レベル API は低レベル API で実装する。低レベル API はテーブルの操作を個別にできるようにすれば良いのかな？と考えて、必要かどうかレビューしてもらったら、高レベル API のみで良かった。

データ定義

いま見てる ER 図は、マスタ系とトランザクション系のテーブルが混在し、さらにそれがテーブル定義書も兼ねている。資料の作り方として、自分なりにメリットとデメリットを考えてみる。

  • メリット
    • 1つ資料に全ての情報が集約されるのでメンテナンスが容易
  • デメリット
    • リレーションに関係ないテーブルがある
    • リレーションの見通しが悪くなる (不要な情報がスペースを占有するから)
    • テーブルのカラムのデータ型や用途、制約を定義するスペースがない

良い悪いのお話じゃなくて、やり方の違いを実感しているところ。ER 図やテーブル定義書を作らない人もいるし、、、。私は基本的にトランザクション系テーブルの ER 図は書かないし、トランザクション系の ER 図が必要な状況があるとしたら、ビジネスロジックの方がおかしいと私は思う。