Q&A
コメントありがとうございます。
新規顧客として登録できない場合、(例えば顧客名が被っているなどのDBの制約違反とか？)注文の新規作成処理だけが先に走ってしまって、顧客登録のない注文処理になってしまい、ロールバックしなければならないとなりませんか？
その逆も然りで、注文が登録できない場合に新規顧客だけが登録されてしまうようなケースもあるとおもうのですが、別々でAPIを呼び出す際はフロントエンド側でそのあたりを制御してあげるべきなのでしょうか？
実現したいこと
フロントエンドをVue、バックエンドをJavaでWebアプリを作成しています。
バックエンドでのAPIの実装のパターンで2つのケースを想定しているのですが、どちらが一般的な手法であるかを知りたいです。
発生している問題・分からないこと
複合的なデータが更新されるケースでのAPIの実装方法がわからないです。
例えば、販売管理システムを考えると、
お客様からの注文を受けた時点で営業担当が何らかのフォームにデータを入力することで、お客様の情報や注文情報などが顧客テーブルや注文テーブルにインサートされると思います。
1つのフォーム処理で複数のテーブルに更新が走るケースでの実装方法ですが、
①バックエンドのAPIをREST APIで実装していた場合、以下のようなURIになると思います。
/api/customer (顧客の新規作成)
/api/order (注文の新規作成)
このような場合、フロントエンドでは顧客のデータを更新するためのAPIをそれぞれ2回呼び出すのでしょうか？
②もしくは複合データモデルを作っておいて、
/api/orderreceive
のようなAPIを一度だけ呼び出したら、その中で顧客の新規作成も注文の新規作成も行われるような形でしょうか？
①だとフロント側の呼び出しが冗長になるのと、API呼び出しを繰り返すことでパフォーマンスに悪影響が出るのではと思っていて、
②だとバックエンドをREST APIで実装していた際に、RESTの原則に反する実装になってしまわないかと思っています。
私はWeb開発初心者のため、認識に間違いがあれば、指摘いただけますと幸いです。また、情報に不足があれば、可能な限り補足しますので、コメント頂けたらと思います。よろしくお願いします。
該当のソースコード
特になし
試したこと・調べたこと
- teratailやGoogle等で検索した
- ソースコードを自分なりに変更した
- 知人に聞いた
- その他
上記の詳細・結果
書籍等もいくつか確認しましたが、初心者向けの書籍では求めている情報を見つけられませんでした。
補足
特になし
回答3件
0
ベストアンサー
こんにちは。
REST の文化などは一旦置いておいて、
自分だったら①の実装を選ぶと思います。
通常フロントエンドとバックエンドはお互いがどのようなものであるかを知っているべきではなく、API のみが共通言語になっているのが良い設計となります。
その上で、顧客と注文というのはそれぞれ全く別のデータの単位であって、担当するサービス部署からして異なるものです。
例えば注文をインターフェースだけで考えると、自然な形は「顧客の識別子と注文の内容を取り、処理を行い正否を返す」ものになると思います。
すなわち、注文は有効な顧客が既に存在していることを前提としているので、顧客の作成は注文というプロセスの責任の範囲外となっています。
そのため、仮にフロント側では注文と顧客作成を同時に行うような振る舞いをさせていたとしても、顧客の作成と注文の作成はそれぞれ別のプロセスとして行われるのが自然です。
ただし、パフォーマンスのために正規化を崩す場合もまたあり得るため、通信がボトルネックになっている場合には②のような実装を選ぶことは考えられます。
それも妥協によるものなので、一般的に①の方が設計として良いものであることは間違いありません。
投稿2024/10/20 02:46
総合スコア4228
0
処理ごとにエンドポイントを増やすとメンテナンスコストがかかってしまうのでは
僕も今回のケースであれば1でつくりますね。
/api/customer (顧客の新規作成)
/api/order (注文の新規作成)
注文主が新規顧客ということの方が少ないでしょう、であれば、2つめのインターフェースが有用になるでしょう。また、何らかの理由で新規顧客として登録できない場合などを考えると、手続として顧客登録と発注を1つにまとめてしまうのはよくないと思います。
投稿2024/10/19 04:59
総合スコア13687
注文APIには、注文主としての顧客IDなどが必須になるはずなので、顧客の登録と注文の処理は並列でしょりすることはできないと考えます。
また、既存顧客の場合にも、注文の前にログインをさせるなどの認証処理を通すのが 一般的と思います。
0
②でも問題ないですし特に問題ないと思います。
RESTの原則に反するとは何を指していますか？
ただ、私なら今回の例では２つのAPIを作ります。
顧客の新規作成 POST /api/customers
注文の新規作成 POST /api/orders
※原則ではないかもしれませんが、一般的にはRESTならリソースは複数形にすると思います
特にVueでフロントエンドを作っているなら注文情報を入力するフォームでは顧客情報を検索または選択できるようなUIにすると思います。未登録の顧客情報の場合は、顧客の登録フォームをその場で呼び出して登録してフォームを閉じる。その後、注文情報の入力フォームで顧客を選択します。
投稿2024/10/19 02:28
総合スコア4190
ご回答ありがとうございます。
複数形が基本でした。失念していました。
RESTの原則に反すると考えている部分は、処理の都合に合わせたAPIのアクセスポイントを作成することがアドレス可読性に反してしまうのではないかと考えています。
処理ごとにエンドポイントを増やすとメンテナンスコストがかかってしまうのではと懸念しているのですが、どうなんでしょうか？
例も示していただき、大変参考になります。
処理の都合というか、リソースとして定義できるものであればエンドポイントにして良いと考えています。
アドレス可読性はリソースを一意なURLで示す事ができる事なので、処理の都合でもそれがURLで一意に表現出来るならありと思います。
私も日々迷いながら調べて設計、実装していますので、これが正解！というのを示せるわけではありませんが^^。
実際に実装を進めていく上でREST原則からずれていってしまう事もありますが、できるだけ従うようにしたいとは思います。REST原則からずれてるよってチェックしてくれるツールがあるわけでもないのでそのへんはゆるくなります。
メンテナンスコスト、継続性を考えると自分はエンドポイントを増やすのを避けるより、いかにシンプルなAPIになるか、テストが書きやすいかを重視します。テストを書きやすい事がメンテナンスのしやすさにつながると考えているためです。
特にRESTはコードによるテストが書きやすいので、テストをどれだけ充実させられるかのほうが重要と考えています。
複雑なAPIはそれだけテストが書きにくくなります。
私はRalis(Ruby)でAPIを実装しているのですが、RSpecというものでテストを書いています。
Javaのほうは分かりませんが、簡単にググったところではJUnitなどでテストを書くのでしょうか。
REST APIを開発、運用していくにはとにかくコードによるテストをちゃんと書く。繰り返しテストが実行できる、不具合があればすぐに見つけられるようにするという事のほうがREST原則に従うかよりも現実的には最重要と感じています。
回答にあたり、私もRESTについて改めてググったりしました。
ちなみにこちらの記事では、顧客の注文を作成するエンドポイントは
POST /customers/1/orders を例として挙げています。
注文の前に顧客情報を登録しておくフローを前提かな。
https://learn.microsoft.com/ja-jp/azure/architecture/best-practices/api-design#organize-the-api-design-around-resources
蛇足ですが、RESTの原則について参考にする際は、個人のブログとかよりもMicrosoftとかGoogleとかある程度信頼がおけそうなところの記事を優先してみるようにしてます。
テストのしやすさという観点はありませんでした。
大変参考になるコメント、アドバイスを頂き、ありがとうございます。
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2024/10/20 03:22