Question

所以我要求部分输出模型必须包含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  
}

Answer 1

您发送到源服务器的表示形式可能与您收到的表示形式完全不同。考虑Web浏览器的工作方式。您获取text/html并发布application/x-www-urlencoded-form。

当使用PUT方法时，如果不相同，PUT和GET的相似性是正常的。

REST架构风格不对HTTP有效负载的形状施加任何限制，除了必须在消息中明确指定语义这一事实。

因此，实际上，在客户端和服务器之间共享模型类型而不在消息中明确标识该类型是违反自描述REST子约束的。

Answer 2

这取决于您希望为客户提供何种灵活性（REST服务使用者）。

如果您维护相同的模型，那么消费者可以加载现有模型，修改值，然后将其发回，这在CRUD场景中非常自然。

但是，如果您希望有两个不同的方案：1-导入数据，2-导出数据，则可能是不同的。

通常，将其视为应用程序中的模型（您的问题域）。定义服务器端模型结构（显然只有一个），然后考虑如何公开它。对我来说，在查看问题中概述的这两个模型时，它们看起来很相似。我甚至建议支持任何输入格式（这些）和一种输出格式（一次，可能取决于请求标题）。

Answer 3

除了数据本身，我还会将元信息保存在单独的对象中。

所以在JSON响应中，第一个对象就像

{ meta:  { priceformat: $, lengthformat: ft },
 thePrice: 3.50,
 length: X
}

REST标准 - 输出模型是否应始终与输入模型匹配？

3 个答案: