Question

总结：API调用的返回对象与必须从调用方提交的对象不同是可以的。

让我举例说明：

给出了两个API： Food 和 Sport （资源），均具有标准的CRUD操作，并且签名是标准的。

示例：

GET：... / resource / {id}
POST：... /资源
PUT：... / resource / {id}
删除：... / resource / {id}

调用PUT / POST要求有效负载包含对象模型，例如 FoodModel 或 SportModel

问题是：让所有调用（GET / POST / PUT / DELETE）返回一个通用数据模型有什么问题，该数据模型具有嵌套的对象，该对象具有需要的序列化资源。

从呼叫者发送的必需模型的示例 ... / 运动

{
  name: "soccer",
  popularity : "high"
}

GET的返回模型的示例... / 运动 / {1}

（！GET返回，而不是POST的响应（也可能是TransactionModel）

{ "TransactionModel":{
                      correlationId: "83abaf27-3e87-43e5-a4ae-29eda793aff5",
                      anotherProperty1 : "...",
                      anotherProperty2 : "...",
                      resourceType : "Sport"
                      resourceValue : {
                                  name : "Soccer",
                                  popularity: "high",
                                  createdDate: "2019-06-05 23:06:32.923"
                                 }

}

为了明确起见，调用这些端点需要在有效负载中使用它们各自的模型（用于POST和PUT），因此 SportModel / FoodModel

我的响应对象是一个 TransactionModel ，其中包含所需的资源模型。所有资源（体育，食品，规则，人等）都将发生这种情况

如果您有任何文章，RFC文档或支持或反对这种方法的任何内容。请同时提供。

谢谢

Answer 1

问题是：让所有调用（GET / POST / PUT / DELETE）返回一个通用数据模型有什么问题，该数据模型具有嵌套的对象，该对象具有需要的序列化资源。

简短回答：否

有些回答：不，不是在理想情况下。但这也不是不可能。

万维网是REST体系结构样式的参考应用程序。 HTML文档通常以资源的表示形式提供，并且您可能已经注意到，与资源状态不直接相关的HTML文档中可能有大量的……仪式？……。

让我们面对现实吧-无论您的表示形式是什么，该表示形式本身都将嵌入到HTTP消息中，并携带其自己的元数据。

重要的是，客户端和服务器对表示的语义有共同的理解。如果设计出这样的共识，以便可以以向后/向前兼容的方式轻松扩展它，那就更好了。

在架构上，资源不仅限于一种表示形式，也不仅仅是一种表示形式。因此，您可以选择同时支持application/json和application/prs.my-custom-app+json，为那些足够有才干的客户提供丰富的实现。

您是否建议，如果仅为“ application / json”指定“ Accept”标头，则响应将是资源的预期模型，例如SportModel。在哪里“ application / pry.my-custom-app + json”将返回“ TransactionResult”模型？

是的，与请求text/plain的客户端所获得的资源表示方式与请求text/html的客户端所获得的资源表示方式完全相同。

这里有一个2008 comment from Roy Fielding，可能会让您更清楚地知道它的来源

REST API应该花费几乎所有的描述性精力来定义用于表示资源和驱动应用程序状态的媒体类型，或者为现有标准媒体定义扩展关系名称和/或启用超文本的标记类型。花费所有精力描述应该在媒体类型的处理规则范围内（并且在大多数情况下已由现有媒体类型定义）完全定义要在感兴趣的URI上使用的方法。 [这里的失败表示带外信息正在驱动交互，而不是超文本。]

Answer 2

不！你没有做错任何事。

但是我更喜欢为每个请求和响应都使用不同的表示对象，因为在项目的初始阶段它看起来很酷，但是随着时间的流逝，对GET响应/请求或说POST响应/请求有不同的要求，这会使您的代码混乱因为您将尝试使用该通用数据模型或说一个表示对象来处理这些事情。

我曾经以与您相同的方式做事，但是后来我逐渐学会了。它现在会增加您的工作，但使您将来的开发变得容易得多。

REST API：用于返回的公共资源模型（包装器）

2 个答案: