それぞれこんな感じにしています。/api/v1/users/1このあたりまではそれほど問題ないかと思っています。問題は次のような機能がある場合です。設計すると良いのでしょうか?以下に自分の意見を記載します。一括削除これについては専用のリソースを設けるしかないかなと思っています。良いのかがちょっと分かりません......。しようかなと思っています)。別レコードを新規作成する等)。良いのでしょうか......?)。レスポンスとして返ってくるようなイメージで良いのかなと思っています(リクエストのエンティティボディは特に無くても良さそう?)。更新される程度だと仮定してみます。呼び出すのと同様の処理で済みます。何だか平仄が合っていないのが気になります。結局これも専用のリソースを作ることに......。更新するだけだとすると専用のリソースを作るべきか悩んでしまいます......。感覚的にはやっぱりここも専用のリソースを作ってこんな感じに......。/api/v1/users/1/lock以上です。不適切なら指摘頂ければ削除します)。アカウントロック」の4つの機能を、どちらのコンポーネントに実装すべきなのかよく考えた方がいいと思います。10個の項目を一括削除する場合は、単純に考えればDELETEを10回繰り返すだけです。その10個の項目が一つのパスの配下にあるなら、その親パスを1回DELETEするだけで済むこともありますし、ある条件にマッチした項目全てということなら?q=hogeのようにクエリーを使うこともできます。いう意味では上記の例について言うと、各種業務機能をバックエンド側で提供する方が平仄が取れて良いのかなと思ったのでそのようにしているのですが、皆さんならどうするのかご意見を伺いたいと思って投稿させて頂きました。例で言うとフロントエンド側で実装することも可能ですが、もしフロントエンドに寄せるならどのような観点でフロントエンドに寄せると判断するのかなと。01:51今回は、バックエンドがRESTであるという前提条件があるのですから、それ以外の部分がフロントエンドなのでは?例えば、リソースの状態変更はPUTです。するということですね。23:08あぁ、すみません言葉の使い方が悪かったでしょうか。アプリケーションのことをフロントエンドと呼ぶと理解出来るでしょうか。08:43あぁ、そういうことですか。サーバーサイドがフロントエンドとバックエンドに分かれているのかと思いました。フロントエンドがサーバーでもクライアントでもアプリケーションとしての構成は同じですが、セキュリティの設計が変わってくるのかもしれませんね。19:12承認処理の内容がいまいちよく分かりませんが。19:20ここでの承認はあくまで例ですが、質問の通りかなり複雑な業務ロジックがあると想定しています。レコードのステータスが複雑に遷移したり、承認前後のレコードが作成されて登録されたり、監査ログが永続化されたりといった具合です。このような業務ロジックはやはりサーバーサイドで永続化することになるのかなと思い、そうすると平仄をとるためにアカウントロック等もサーバーサイドに寄せるべきなのかなと考えていました......。20:12えーと、ですから、「承認処理は複雑である」という説明だけだと内容がよく分からないのでこれ以上答えられません。逆にいうと、「承認処理は複雑である」と大雑把な考えかたをしているからうまく設計できないのでは?もっと処理内容の詳細を整理した方がよいと思います。さんの質問に答えると「PUTし直す、という形にはならない」ケースを考えています。詳細な内容はあるのですが、それを書くことは出来ないのでここでは例として「承認」のように「クライアントで実装するのが困難と思われるような処理」と「ロック」のように「クライアントでも実装出来そうな処理」が共にある場合、一般的には皆さんはどのように設計するんだろうというのが知りたいところでした。01:24ちょっと質問の仕方が悪かったですかね......。ここ日本語サイトなので皆さんならどうするんだろうという意見が聞けるかなと思ったのですが、場所を変えます......。DELETEするという手もあるみたいです。サーバーがuniq_idを作成し、クライアントはuniq_idを手に入れる。/api/v1/users/selections/{uniq_id}とするようです。uniq_idはどうするんだろ。冪等性のために持ち続けるというのもイマイチな気も。(0)回答ありがとうございます。コミットするという感じですね。少々迂遠過ぎる感じもしますね......。20:15ウォッチこの質問への回答やコメントをメールでお知らせします。