3

このプロジェクトでは、書籍の構造 (XML、JSON など) を POST または PUT リクエストで送信することにより、書籍を追加できます。たとえば、XML では、本の構造は次のようになります (単純化されています)。

<book>
    <title>My Book</title>
    <author>John Q.</author>
</book>

この書籍がバックエンド データベースに挿入されると、作成日、書籍を送信したユーザー ID、識別子など、いくつかの自動生成されたプロパティが自動的に追加されます。

GET を使用してブックを取得すると、次の追加のプロパティがブック定義に含まれます。

<book>
    <title>My Book</title>
    <author>John Q.</author>
    <info>
        <creation_date>2011...</creation_data>
        <user_id>48</user_id>
        <identifier>my_book_john_q</identifier>
    </info>
</book>

これは基本的に、新規/編集された本 (= クライアントからサーバーへ) の XML スキームが、取得された本 (= サーバーからクライアントへ) とは異なることを意味します。これは物事を混乱させます。

これらの追加のプロパティを別の URI で使用できるようにすることもできます。たとえば、次のようになります。

http://server/books/:id/             -> returns the short version
http://server/books/:id/information/ -> returns the generated properties

このアプローチの欠点は、すべてのデータを取得するために 2 つの別個の要求が必要になることです。

この矛盾をどのように解決しますか？

4

2 に答える 2

5

これは完全に正常です。サーバーが何らかの追加情報で表現を拡張しても問題はありません。この良い例は、サーバーが表現にリンクを追加する場合です。PUT を実行するときに、クライアントがこれらのリンクの「コピー」をサーバーに送信する必要はありません。GET および PUT するリソース表現は概念的に同じである必要があり、必ずしもバイトごとに同一である必要はありません。

于 2011-07-16T19:28:33.023 に答える
0

MIME タイプを正しく使用していません。一般的な MIME タイプを使用していてapplication/xml、クライアントはエンドポイントに基づいて何を期待するかを知っているはずですよね?

問題に対処する適切な方法は、同じリソースに対して異なる MIME タイプを使用して異なる表現を使用することです。たとえばapplication/vnd.yourcompany.book.short+xml、短い表現にはapplication/vnd.yourcompany.book+xmlを、完全な表現には を使用できます。クライアントは、Content-Typeヘッダーを使用して送信するものを指定し、ヘッダーを使用して必要なAcceptものを指定できます。

これは、クライアントが POST または PUT で短い表現を送信する必要があるという意味ではありません。一部のフィールドをオプションとして文書化することができ、クライアントがそれらを省略してもまったく問題ありません。

于 2015-11-24T19:41:19.773 に答える