前回に引き続き、会社恒例の3泊4日のプログラミングキャンプで、
RESTful APIの設計の際にRESTful APIのPOSTやPUTのレスポンスについて、
思ったことがあったので投稿してみました。
RESTful APIの設計をチームの先輩がSwaggerで作成してくれるということで、
完成したものを確認していると...
（ふむふむ、一覧を取得するときのpathはこれで、一覧のレスポンスはこんな感じで返せばいいのか）
（新規作成するときのpathはこれで、新規作成が成功した場合のレスポンスはこんな感じで返せばいいのか）
（ん？あれ、新規作成のレスポンスに、登録した情報をレスポンスとして返してるな）
（でも、新規作成した後は、一覧画面に遷移するから、登録した情報を返しても使わないんじゃないか？)
っと思ったので、作成してもらった先輩に質問してみた。
僕 「すみません、新規作成が成功した場合に、登録した情報をレスポンスとして返しているのですが、どうしてでしょうか？」
先輩 「今回の作成するシステムでは使用しないけど、一般的にRESTful APIのPOSTやPUTの場合は結果のリソースを返すことはよくあるんだよ」
僕 「そうなんですね！ありがとうございます！」
（RESTful APIにそんなルールがあったなんて、知らなかった...）
RESTful APIのPOSTやPUTのレスポンスについて調べてみた
POST メソッド
POST メソッドは、新しいリソースを作成すると、HTTP 状態コード 201 (Created) を返します。 新しいリソースの URI は、応答の Location ヘッダーに含まれています。 応答本文には、リソースの表現が含まれています。
5. POST/PUTでもレスポンスボディを返す
APIを使った開発においてよくあるのがPOST/PUTでデータを更新した時に、最新のデータをGETで取り直すというものです。これは2回APIアクセスする必要があってムダです。POSTで作った、PUTで更新したデータについて、その最新の状態をレスポンスに含めるようにしましょう。
特にサーバ側で処理されるデータがある場合、クライアント側ではデータがどういった値を持つかは分かりません。その結果、GETでアクセスする必要が生じてしまいます。ネットワークはボトルネックになりやすいので、クライアントからのアクセスを少なく済むようなサーバ側の実装を心がけましょう。
調べてみて
そもそも、RESTful APIの設計は複数のシステムから呼ばれることを想定しないといけないらしい、
すぐに登録した情報や更新した情報を取り直す場合があるから、レスポンスに登録した情報や更新した情報を入れておいたほうが、使いやすい場合があるんだなと勉強になりました。