10

そのため、出力モデルの一部に UI の重要な情報を含める必要があるという要件があります。この情報は、基本的にテキストの翻訳と、日付、価格、長さの推奨形式です。

したがって、出力モデルの例は次のようになります。

{
  statuses : {
    enumValue1 : "Display This Text",
    enumValue2 : "Display This Text2",
  },
  thePrice : {
    value : 3.50,
    formattedValue : "$3.50"
  },
  length : {
    meters 3,
    formattedValue : "3 ft."
  },
  iAmAPropertyOnlyInGet : 42
}

これを出力モデルとして使用している場合、完全に異なる入力モデルを使用しても問題ありませんか?

{
  status : {
    enumValue1,
    enumValue2,
  },
  thePrice : 3.50,
  lengthInMeters : 3  
}
4

3 に答える 3

9

オリジン サーバーに送信する表現は、受信する表現とは完全に異なる場合があります。Web ブラウザの仕組みを考えてみましょう。あなたは GETtext/htmlし、あなたは POST しapplication/x-www-urlencoded-formます。

PUT メソッドを使用する場合、PUT と GET が同一ではないにしても、類似しているのは普通のことです。

REST アーキテクチャ スタイルでは、メッセージでセマンティクスを明示的に指定する必要があるという事実を除けば、HTTP ペイロードの形状に制約はありません。

したがって、実際には、メッセージでそのタイプを明示的に識別せずにクライアントとサーバー間でモデル タイプを共有することは、自己記述的な REST サブ制約に違反します。

于 2012-11-06T23:50:57.553 に答える
2

それは、クライアント (REST サービスの利用者) にどのような柔軟性を与えたいかによって異なります。

同じモデルを維持する場合、コンシューマは既存のモデルをロードし、値を変更してから送り返すことができます。これは、CRUD シナリオでは非常に自然なことです。

ただし、1- データのインポートと 2- データのエクスポートという 2 つの別個のシナリオがあると予想される場合は、異なる可能性があります。

一般に、アプリケーション (問題のドメイン) のモデルと考えてください。サーバー側のモデル構造を定義し (これは明らかに1 つだけです)、それを公開する方法を考えます。私には、質問で概説されているこれら 2 つのモデルを見ると、似ているように見えます。任意の入力形式 (これらのいずれか) と 1 つの出力形式 (一度に、要求ヘッダーに依存する場合があります) をサポートすることをお勧めします。

于 2012-11-06T17:56:44.033 に答える
0

データ自体とは別に、メタ情報を別のオブジェクトに保持していたでしょう。

したがって、JSON 応答では、最初のオブジェクトは次のようになります

{ meta:  { priceformat: $, lengthformat: ft },
 thePrice: 3.50,
 length: X
}
于 2012-11-06T18:31:54.390 に答える