0

ユースケースの単純化ですが、顧客の注文を処理するための REST サービスを作成したいと考えています。

RPC の世界では、RPC エンドポイントを作成します

OrderProduct(CustomerID, ProductID, Quantity)

これは

  • 注文 DB レコードを作成する
  • Product DB レコードの利用可能な在庫を減らす
  • ストックピッキング用のワークリスト テーブルにエントリを作成する

（私の実際のユースケースではありませんが、私がやっていることよりも理解しやすいです）

私の REST アプローチでは、Customer、Product、および Worklist の POST エンドポイントが既にありますが、3 つすべての呼び出しを 1 つのトランザクションで結合する必要があります。私の問題は、ワークリストへの挿入が何らかの理由で失敗した場合にロールバックできることです。

それでは、POST のみを公開する ProductOrder エンドポイントを作成することは適切でしょうか?

POST を処理するサービス内で、DB トランザクションを作成し、データベースと直接やり取りして、関心のある 3 つのテーブルを更新します。

私の緊張は周りにあります

  1. 既に公開したエンティティ エンドポイントを再利用しない。
  2. RPC タイプの呼び出しを処理するためだけにエンティティを発明する (したがって、POST のみを実装する)

ありがとう、アンディ

4

1 に答える 1

0

TLDR: 心配しないでください! RPC ではなく、概念エンティティの観点から考えてください。疑わしい場合は、GET、POST、およびオプションで PUT と DELETE を使用して新しい RESTful エンティティを作成します。

「ProductOrder」エンドポイントが必要ですが、「Order」と呼ぶだけです。「注文」DB レコードがあるため、それをシステム内の他のエンティティと同じ REST ワークフローに公開することは理にかなっています。

既に公開したエンティティ エンドポイントを再利用しない。

する理由はありません。製品と顧客の REST エンドポイントは、注文を作成するのに役立ちません。注文自体はシステム内の概念的なエンティティであり、複雑なライフサイクル (注文の検証、注文ステータスの追跡、在庫の減少、資金の移動) にまたがるさまざまなステップを含む可能性があるためです。 ）。REST クライアントはすべてのステップを知る必要はありません。注文の作成には Order エンドポイントへの POST が必要であることだけを知っている必要があります。

RPC タイプの呼び出しを処理するためだけにエンティティを発明する (したがって、POST のみを実装する)

それがポイントです。「GET」、「POST」、「PUT」、または「DELETE」が可能な「Order」エンティティがあります。アイデアは、GET /customers/{id}/orders を使用して顧客の合計注文を取得したり、/orders/{id} または /customers/{id}/orders を使用して特定の注文に関する詳細を取得したりできるということです。 /{id} または POST /customers/{id}/orders を使用して新しい注文を作成することもできます。

Order は、すべての標準的な RESTful 操作を適用できるエンティティになります。

于 2013-07-26T14:08:20.543 に答える