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

如何解决根据消费者请求构建 Rest API 响应对象

我正在构建 rest 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,shelfTags --> **consumer 5**
6.  product,shelfTags --> **consumer 6**
7.  etc...

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

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

注意：我不能将所有嵌套集合与产品端点 1 本身一起包括在内，因为它需要大量数据查询，所以我计划只提供消费者可能需要的东西，这将减少不必要的查询并提供对不需要这些数据的少数消费者而言不相关的信息。

当前设计：

我现在有以下内容：

方法一：

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

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

方法 2：

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

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

在选项 2 中，extendedProductDetails 是操作而不是资源本身，我正在对操作进行过滤。

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

解决方法

方法 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 请求变得非常简单:)

,

也许解决方案是在请求标头中使用自定义媒体类型：

application/json+info-only
application/json+supplier
application/json+supplier+packages
etc.

在您的控制器操作中，您将检查选定的媒体类型并根据它们响应请求。只需返回一个 IActionResult，您的消费者就会在一个请求中获取数据。

它与您的方法非常相似，但使用自定义扩展媒体类型时，您仍将拥有一个没有其他参数的端点。