Web API: The Good Partsを読んだ

Web API: The Good Partsを読んだのでざっくり感想。

この本は一般に公開されているAPIを例に書かれて、APIのエンドポイントやヘッダのことなど色々網羅されている印象があり、自分が知識が足りない部分を補える感じで良かった。

一番の収穫はヘッダ部分のこととかだった。基本的に余りヘッダの内容など意識しないでAPIとかを書いていたので、意識してちゃんと使っていかないとなと反省した。

エンドポイントの部分とか自分がこうするべきと思っていることと一致していた。 実際には、思っていただけで出来てはいなかったので今年移ったところでは意識するようにしていて基本的にはするようにしている。

実際のところ、HTTPメソッドの使い分けとかはしたいけど、どうしようかってチームの人と話したけどGETとPOSTでやることにした。TwitterもGETとPOSTだけだし。

エンドポイントの作成って難しいなと思ったりする。REST準拠とかいっても単純にはいかない。

複数のリソースにアクセスする処理は絶対存在するし、別々にリクエストを投げるとトランザクションが変わるので整合性が取れない。そういうときのエンドポイントどうしようかなと悩む。こういうことはこの本には書いていないので注意。

上記の例ではないけど、例えばソシャゲで言えばユニットの合成とかのエンドポイントはどうするか。 下記のようなものが考えられる。

POST/PUT /units/:unit_id
{
  "material_unit_ids": {"type": "array", "items": {"type": "integer"}}
}

POST/PUT /players/:player_id/units/:unit_id
{
  "material_unit_ids": {"type": "array", "items": {"type": "integer"}}
}

POST/PUT /units/compose
{
  "base_unit_id": {"type": "int"},
  "material_unit_ids": {"type": "array", "items": {"type": "integer"}}
}

POST/PUT /players/:player_id/units/compose
{
  "base_unit_id": {"type": "int"},
  "material_unit_ids: {"type": "array", "items": {"type": "integer"}}
}

こういうものは普通に沢山ある。 そういうときにどうするべきかは分からないけど、一番大切なのはエンドポイントを見て何が行われるかすぐに理解できることだと思う。

それを意識して書くことが一番大事(だからといってエンドポイントを増やしすぎるのもいけないと思う)。