⚡
API利用者のことを考えた実装
経緯
最近いただいたアドバイスで、APIの実装の方針が実装者の都合に寄りすぎているというものがありました。
最終的な実装に至るまで様々なことを考えるきっかけになったので、覚えておきたいためまとめます。
具体
極端な例を挙げます。
APIの実装の際、下記のような値がレスポンスになるような実装をしたとします。
GET /api/humans/1
nicknameは任意の値で、DBで空文字が許容されています。
ここで、IDが2のユーザーを取得したいときに、APIの利用者は次のリクエストを送ります。
GET /api/humans/2
この際のレスポンスが仮に以下のように実装されていたとします。
どのような問題が起こるでしょうか。
実装者側からすると「nicknameは入力されていない場合もあるから、無かったらキーも無しにしよう」という気持ちで実装したのかもしれないですが、利用者側からすると「nicknameがない場合は、keyがない時の例外処理を書かないといけないのか…」という気持ちになります。
学んだこと
利用者の立場になって実装する、というのはこれまで自分の経験からすると、見やすい画面だったり、重くならない処理だったり、何かあった場合の回避策が実装されていたりなどを想像していましたが、こういった「利用者のことを考える」必要もあるのだと思いました。
言語化が少し難しいですが、相手が何を期待しているかと考えたときに、APIの利用者が期待することを自分が想定しきれていなかったことを痛感しました。
ではどうするか
APIの設計や、REST API、例外処理などの知見をもう少し深めた方が良いと思ったので勉強します。
「利用者」に関してももう少し深掘りして考えることで、より良い実装になると思っています。