apiの設計について

質問

apiのレスポンスについて質問です。
ある書籍で、登録・更新apiのレスポンスでは登録値は返さず、取得apiで再度取得した方が良いとありました。
それはそれで、再度apiを呼び出すコストがかかると思うのですが、それよりもapiをシンプルに保つ方が良いのでしょうか、
個人的にはリクエスト回数は少ない方が良いような気がしております。
その辺の知見をご教授頂ければと思います。

回答No.1

dell_OK · ベストアンサー

「再度取得した方が良い」とする理由は書かれていましたか。参考までに私が知っておきたい気もしますが、返答されなくてかまいません。
私の経験では、登録するものは登録する機能、取得するものは取得する機能、と言う風に、機能を単純化するように指示されたことがありました。ＡＰＩに限った話ではないと思います。
「登録値を返す」ですが、その登録値が呼び元にあるのなら返す必要はないと思います。どのようなＡＰＩの想定かわかりませんが、例えば、登録した際にユニークな連番が振られるのでそれを返す、と言うのならわからないでもないです。
もしその書籍が登録直後にでも取得するようすすめているとしたら、登録と取得の間に、例えそれが瞬間的だとしても、他から値が変更されているかも知れない想定かも知れません。
私が単純化するよう指示された意図には他に、例えば登録する機能を「PutData」と命名したとします。もしこれが値を返すとなったら、機能名で機能が判断しづらくなってきます。値も返ってくるんだとしたら「PutDataAndGetData」と言う奇妙なものになりますし、それなら「PutData」の後で取得機能の「GetData」を呼べばいいように思います。
ではなくて「PutData」の内部で「GetData」をしているすると、登録だけしたい場合に使えないものになってしまいますし、使おうとするには取得不要を示す引数が必要になってくるかも知れませんが、おそらくＡＰＩによっては戻り値を受け取る領域の型や大きさをきちんと用意しておかなければならなかったりするので、必要のない時まで返ってくる登録値用の領域の確保（単なる変数かも知れませんが）や取得しないなりに空のデータの受け取りが処理される（コストがかかる）ことになると思います。
とは言え、登録と取得、更新と取得、と言う決まりきった仕様で、他で利用されることがないのであれば、登録値を返してもいいとは思います。言われるように、別々になっていたらいくらかのコストがかかるとは思います。
あとは、登録機能は登録に成功したか失敗したかを示す値を返すのが一般的だと思います。それはたいてい失敗した場合は処理を続行しないようにするためだと思います。仮に登録値を返す仕組みとして、失敗した時には例えばnullとか0x00とかを返すとかで判断できるのかも知れませんが、そうすると登録値にnullや0x00が使えないことになるので、場合によっては困るかも知れません。
そんなこんなの場合を考えるよりも、機能をシンプルにした方が世のため人のためなのかも知れません。
もしコスト重視な場合は、必要十分なデータ量を通してテストして、それからＡＰＩの仕様を変更してもいいのではないでしょうか。
私はＡＰＩは使うばかりで開発はほとんどしていないので、あくまで個人的な考えです。

補足

「再度取得した方がいい」というのは、登録のapiでは登録処理のみ行うのが好ましいということでした。