2

REST-ful Web サービスを考えると

/product/{product-id}

Content-Type の Product XML ドキュメントを返す

x-esvc/product+xml

私も応援しなきゃ

x-esvc/prices+xml

(x-esvc はカスタム MIME タイプです。製品と価格は 2 つのサブタイプであり、+xml はRFC 3023に従って XML ベースの形式であることを示しています)

問題は、この 2 番目の形式が独自の Web サービスを持つべきかどうかです。

/prices/{product-id}

...または、コンテンツ ネゴシエーションと Accept HTTP ヘッダーを使用して、既存の製品 Web サービスの 2 つの形式を区別する必要があるかどうか?

関連する実際のエンティティ (製品) は 1 つだけであり、「価格」は OO 用語による依存オブジェクトのリストであることに注意してください。ただし、どちらの場合も同じ識別子を使用できます。

問題を定式化する別の方法は、「価格」が同じリソースの異なる表現と見なすことができるかどうか、または情報が異なる場合に別のリソースと見なす必要があるかどうかです。

コンテンツ ネゴシエーションは通常、同じ画像に対して JPG と PNG などの異なる技術フォーマットを区別するために使用されることを知っています。つまり、情報は同じですが、形式が異なります。この場合、コンテンツ ネゴシエーションは、同じエンティティの異なる情報を区別するために使用されます。

これは、コンテンツ ネゴシエーションと Accept HTTP ヘッダーを REST-ful Web サービスで有効に使用できるでしょうか?

4

1 に答える 1

0

私は別の Web サービスを好みます。URL のみを指定するだけでリクエストを完全に表現できるため、すべての消費者による使用が簡素化されます。これは、プロジェクトの現在の段階では無関係かもしれませんが、進化するにつれて変化する可能性があります。リクエスト ヘッダーをいじる必要なく、Web サービス呼び出しを組み立てて維持する方が簡単です。

サーバー側でこの分離を必要としない/したくない場合でも、Web サーバー構成のディレクティブによって 2 つの URL の場所を統合できます。

Web サービスの操作も簡単になる可能性があります。負荷分散とメンテナンスのダウンタイムを考えてみてください。

プロジェクトの規模に応じて、マイレージは異なる場合があります。社内の PoC の場合は、持っているものにしがみつくのが最善でしょう。

于 2013-03-13T13:55:49.400 に答える