时间戳

首页 > 解决方案 > 根据消费者请求构建 Rest API 响应对象

api - 根据消费者请求构建 Rest API 响应对象

问题描述

我正在构建休息 API，以下是我的终点。

EndPoint 1:

/products/{code} --> giving product inforamtion

Endpoint 2:

/products/{code}/packages --> provides packages for a given productcode

Endpoint 3:

/products/{code}/suppliers --> provides suppliers for a given product code

Endpoint 4:

/products/{code}/shelfTags --> provides shelfTags for a given product code

我们有多个下游系统（超过 20 个下游系统）需要产品及其相关信息。

注：并非所有用户都需要嵌套集合信息，有些客户只需要产品信息，它们很好，以下是组合，因消费者而异

1.  product info only --> **consumer 1**
2.  product ,  packages --> **consumer 2**
3.  product, suppliers, packages--> **consumer 3**
4.  product, supplier, packages, shelfTags--> **consumer 4**
5.  product, supplier, shelfTags --> **consumer 5**
6.  product, shelfTags --> **consumer 6**
7.  etc...

从上面的示例中，消费者 4进行 Http 调用以获取产品代码，现在必须进行多次 Http 调用以获取包（端点 2）或供应商（端点 3）或货架标签（端点 4）等......这是一个好的设计吗？

有没有一种方法可以让消费者在一个请求中只得到他们想要的东西？（现在在一个请求中提供数据需求是一种好的设计吗？还是要求消费者进行多次 Http 调用以获取嵌套集合？）

注意：我不能包含所有嵌套集合以及 Products Endpoint 1 本身，因为它需要大量数据查询，所以我计划只提供消费者可能需要的内容，这将减少不必要的查询，并为少数不需要的消费者提供不相关的信息那个数据。

当前设计：

我现在有以下：

方法一：

/products/{code}?Options = packages, Suppliers

上面将给出产品详细信息并有选项查询参数，基于我可以决定是否传递包和供应商、货架标签等，但这里我们没有过滤资源以传递查询参数，我认为这不是查询参数的好方法仅用于过滤资源。

方法二：

形成一个不同的端点，因为资源上的查询参数仅适用于过滤器，如果我没记错的话，请查看以下选项：

/products/{code}/extendedProductDetails?Options = Packages, Suppliers

在 option2 extendedProductDetails 是一个操作而不是资源本身，我正在过滤操作。

谁能提供有关如何解决此要求的解决方案

标签： apirestasp.net-web-apiasp.net-core-webapi

解决方案

方法 1与方法 2

假设您想使用 REST，从我的角度来看，在您提供的选项之间，我会使用类似方法 2的方法，因为它是扩展信息的适当集合。但是，我认为我更喜欢将其建模为/products-extended/{code}?options=packages,suppliers，因为它定义了不同的集合。

除了增强 API 的可读性之外，通过这种方式，您拥有products集合和products-extended集合：它们中的每一个都可以独立使用并使用不同的查询字符串过滤器（当然，较少的过滤容易增加复杂性和延迟，但在我的意见，查询字符串参数应该是可选的）。如果它们真的不是可选的，并且总是需要提供一个product id且至少一个嵌套集合，那么，您还可以考虑设计类似products-extended/{code}/{packages,suppliers,etc}. 无论哪种方式，这都会“保护”您的products收藏。

此外，如果您的用例需要，这将允许您对两个集合执行不同的操作（POST、PUT、...）。

其他方法

除了关于 GraphQL 的其他建议 - 会很棒，是的 :) - OData 或自定义类型，你不能只保留单个集合吗？根据您的用例，也许您可​​以对 执行并行调用/products/{code}/packages，/products/{code}/suppliers等等，因为您已经知道product id. 也许，这种设计的主要缺点是，例如，创造新产品。但是，GET 请求变得超级简单 :)

推荐阅读