Question

因此这个后端将由ad-hoc前端应用程序使用。但也将由其他系统集成，我们将为它们公开API。

在设计其余部分时，我看到有一个数据库表（我们称之为表A）可以连接许多其他表，比如大约10到20个其他表。

现在，我的策略是在我的后端建立路线，根据我们的临时前端“推理”。

因此，如果前端中有一个页面（让我们为page1调用此页面）需要从表A中获取行，而且还需要说3个其他连接表中的字段，那么我想在后端创建一个路由称为“page1”，它将返回表A中的行以及其他3个表。

这当然是建立后端的一种普通方式。但由于它也将被其他系统使用，因此有人可能会争辩说这些系统可能不需要路径“page1”。他们的前端可能永远不会构建“page1”。

因此，根据这里的人们说，最好更加灵活地构建API。而不是创建路径“page1”我应该根据“hateoas”构建它。如果我理解这个原则，而不是让我的ad-hoc前端请求资源“page1”，它将请求“pageForTableA”。然后，资源“pageForTableA”应返回哪些是可能要连接的表。

在这种情况下，对于我的前端页面1，我需要向服务器发出4个后续请求，而不是像我想要做的那样，如果后端有“page1”资源。

您怎么看？

我也看到了一个三重策略。我不知道这个模式是否有名称，但它会是这样的：

后端中的资源，仅返回表A中的行。但是，路由也接受参数。参数是一个数组，其中包含有人想要包含的所有其他表的名称。

所以如果前端打电话：

getTableA(array('tableB', 'tableD', 'tableF'))

然后资源将包括/加入表B，D和F.简而言之：API资源让前端决定它想要交付的内容。

您认为这3种策略中哪一种最好？或者还有一些可以考虑的因素？

Answer 1

您需要以消费者不应该知道数据如何存储在底层数据存储中的方式构建您的API。

此外，如果您希望允许消费者决定您希望在响应中投影哪些字段，则可以使用某种查询字符串格式为其提供。

顺便说一句，也许你应该避免重新发明轮子。有一个名为Open Data (OData)的标准已经定义了许多你已经在API中已经要求的东西，并且由于它是由微软制造的，因此它对.NET有很深的支持。