REST 设计模式 1 端点，不同的对象返回类型答案

【问题标题】：REST Design Pattern 1 endpoint, different object return types [closed]REST 设计模式 1 端点，不同的对象返回类型
【发布时间】：2017-06-06 14:21:38
【问题描述】：

我正在尝试确定从 1 个 REST 端点返回不同对象的最佳方法。

示例：

假设客户有一个客户 ID：123 并调用GET /api/customers/123

我当前的设计有多个 PUT 端点来支持独特的更新

我看到的问题是客户端现在必须调用另一个端点来对商业客户执行更新，这使得 API 使用起来更加复杂，我不确定从 1 个 GET 端点返回不同对象类型的最佳实践.

是否有任何替代方案或这种方法是否合理？

编辑：所以我认为我的问题更多是因为我认为这些实体是真正独特的，而事实上它们是相同的（除了一些元数据属性）。 @Patrick Hofman 和 @LB2 为您解答。我会重构

【问题讨论】：

我没有看到 REST API 层因为您添加了端点而变得更加复杂！显然，您只需要准备一些文档...
两个端点如何相互关联？
@PatrickHofman 检索个人或企业信息的唯一方法是通过单个 GET。 PUT 请求之间没有关系，因为它们正在更新单独的实体。
那么在 GET 中与它们有什么关系？
@PatrickHofman 他们都是相同的基本类型，客户。他们确实共享一些属性，但大多数都是独一无二的。例如，如果我要更改个人姓名，它将是名字和姓氏，但企业是他们的经营名称

【解决方案1】：

您可以使用HATEOAS 作为指导客户相应资源所在的方式。

支持GET 调用的模型几乎将结合两个模型的数据属性——这是否是一个好主意实际上取决于您的Business 和Customer 模型的不同程度。如果有理由接近相似但有微小差异，那么组合可能是合理的。

但是，对于每种类型，您将为PUT 生成正确的链接，指导客户端在哪里进行更新。发送什么更新取决于您的服务和客户之间的合同。

【讨论】：

我已经为实体各自的 PUT 端点实现了 HATEOS 链接，我喜欢 API 变得“可自我发现”。我确实喜欢将这两种模型结合起来的想法，因为它可以消除我目前拥有的复杂映射（CustomerBaseModel -->（IndividualModel，BusinessModel））。