QA@IT

monzou

レベル 15

サイト内ランキング 284

    ┗ 3位 (過去30日)

過去最高月間ランク 2

質問数 1件/回答数 0

投稿した質問の解決率 0% (0 / 1)

登録日 2013年8月9日

回答

タグ

アクティビティ

コメント
REST API の設計について教えて下さい
ちょっと質問の仕方が悪かったですかね……。ここ日本語サイトなので皆さんならどうするんだろうという意見が聞けるかなと思ったのですが、場所を変えます……。ありがとうございました!
コメント
REST API の設計について教えて下さい
stripe さんの質問に答えると「PUTし直す、という形にはならない」ケースを考えています。勿論詳細な内容はあるのですが、それを書くことは出来ないのでここでは例として「承認」のように「クライアントで実装するのが困難と思われるような処理」と「ロック」のように「クライアントでも実装出来そうな処理」が共にある場合、一般的には皆さんはどのように設計するんだろうというのが知りたいところでした。
コメント
REST API の設計について教えて下さい
回答ありがとうございます。お~なるほど一連のトランザクションをリソースと考えて、選択したレコードの ID を POST したらサーバー側で削除トランザクションのリソース作成 → コミットするという感じですね。まぁしかし少々迂遠過ぎる感じもしますね……。
コメント
REST API の設計について教えて下さい
ここでの承認はあくまで例ですが、質問の通りかなり複雑な業務ロジックがあると想定しています。レコードのステータスが複雑に遷移したり、承認前後のレコードが作成されて登録されたり、監査ログが永続化されたりといった具合です。このような業務ロジックはやはりサーバーサイドで永続化することになるのかなと思い、そうすると平仄をとるためにアカウントロック等もサーバーサイドに寄せるべきなのかなと考えていました……。
コメント
REST API の設計について教えて下さい
あぁ、すみません言葉の使い方が悪かったでしょうか。stripe さんの仰る「フロントエンド」と「クライアント」の意味が分かりませんが、質問にある通りクライアントは Web ブラウザです。Web ブラウザで動作している JavaScript アプリケーションのことをフロントエンドと呼ぶと理解出来るでしょうか。
コメント
REST API の設計について教えて下さい
なるほど stripe さんはクライアントに寄せて PUT にするということですね。ちなみにこのケースで言うと「承認」のように複雑な業務ロジックがあるようなケースもやはりクライアントで実装して PUT するイメージなのでしょうか?