0

2 つのリソース (ResourceA と ResourceB) を処理する 3 つの安らかなサービス (ServiceA、ServiceB、ServiceC) があります。リソースのメディア タイプは、application/hal+json です。

  • ServiceA が ResourceA を生成します。
  • ServiceB は ResourceA を消費し、ResourceB を生成します。
  • ServiceC は、ServiceA から ResourceA を取得し、それを ServiceB にポストすることによって、ResourceB の生成を調整します。

このやり取りを整理するには、基本的に 2 つの方法があります。

  1. ResourceA 直接仲介者としての ServiceC

    • ServiceC は ServiceA から完全な ResourceA を取得します
    • ServiceCはそれをServiceBに投稿します
    • ServiceB が ResourceB を返す

  2. ResourceA 間接仲介者としての ServiceC

    • ServiceC は ServiceA の ResourceA へのリンクのみを取得します (たとえば、ResourceA の作成時に Content Location ヘッダーを介して)
    • ServiceC はこのリンクを ServiceB に投稿します (HAL メディア タイプのリンク rel を使用)
    • ServiceB は完全な ResourceA を ServiceA から直接取得します
    • ServiceB が ResourceB を返す

最初のアプローチは「古典的な」もののようですが、2番目のアプローチは、ResourceAの完全な送信が2つ（ServiceA -> ServiceC -> ServiceB）ではなく1つ（ServiceA -> ServiceB）であるため、安価です。理想的には、ResourceA が十分に大きい場合は、2 番目のアプローチが適しています。

2番目のアプローチを使用しても問題はありますか? これは「アンチパターン」と見なされますか、それとも何らかの方法で安全/推奨されませんか? より良い相互作用パターンはありますか?

4

1 に答える 1

0

任意のアプローチを使用できます。2 番目のアプローチでは、ServiceA が ServiceB からアクセスできることを確認する必要があります。アクセス可能である場合、実際には、調整のためにまったく別のサービス、つまり ServiceC が必要な理由を推測できません。ServiceB は、ServiceA のイベントに直接サブスクライブできます。何らかのポーリングを使用する予定がある場合は、http://resthooks.org/を参照することをお勧めします。これにより、ネットワーク呼び出しが減少し、サーバーのパフォーマンスが向上します。

于 2015-06-30T06:12:41.880 に答える