💀

API設計をしたときにしくじったこと

2021/08/10に公開

date: "2016-03-16 15:00:00 +0900"

API 設計をしたときにしくじったこと

今、関わっている Web アプリケーションの API を設計する際に

しくじったことを列挙していくポエムです。

API を使うクライアントも自分で作る状態だったので、とりあえず

行き当たりばったりで進めていった結果、共通のお作法が存在しない状態に

なってしまった。

大抵は、応答コードだけでなんとかなります。ただし、更新時のバリデーション

エラーなど、何がどうエラーだったのかを返そうとすると、応答コードだけでは

全然足りません。そして、エラーの返し方を共通化しておかないと、API によって

エラー発生時の応答が変わってしまい、クライアントを作る人が悲惨です。

これはしくじりなのかまだ決めかねているけれども、なんか微妙なのでしくじりに

しておきます。例えば、テーブル A とそれに紐付く B があったとして、素テーブル

操作っぽい API だと、A を全件取ってくる →A をループして紐付いた B を取得する。

というような処理は割とよくあると思うのですが、これを API として提供した。

性能問題が出るより JOIN して渡した方が良いだろうと。その結果、API の数が

増えてしまい、どれ使ったら良いんだろう？と悩む状態になることがしばしば発生。

API のシンプルさと実務的な側面をどうバランスさせるのかは非常に悩ましい。

美しさだけなら、シンプルな API だけ用意してあとはがんばれ！で良いのですが…