Web 服务设计：rest api 应该发回一半信息还是全部信息？
Web service design: should a rest api send back half or all information?
关于在拥有另一半信息时如何响应 restful 网络请求的小问题。
我想坚持认为这不是一个基于意见的问题，因为我相信应该有一个关于该做什么的最佳答案。
场景：
某些客户服务 SERVICE_A 是一种允许客户购买产品的服务。
然而，SERVICE_A只知道产品。也就是说，SERVICE_A不知道商品的价格，需要调用SERVICE_B来实时获取商品的价格。话虽如此，SERVICE_A，只知道一半的信息，只知道产品，不知道产品的价格。
客户将通过 SERVICE_A 前端 select 产品。客户不能去其他服务。然后 SERVICE_A 将通过 API 使用产品调用 SERVICE_B (1)。
像 :
{
"product": "someProduct"
}
然后，SERVICE_B 将收到请求 (2)，然后使用他知道的自己的算法计算价格 (3)。
完成后，SERVICE_B 会将价格 return 发送给 SERVICE_A (4)，后者现在拥有所有信息并可以将其显示给客户。
在第（1）点，SERVICE_A只知道了一半的信息。只有产品。
在第（2）点，SERVICE_B收到请求后也只知道一半的信息，只有产品。
在第(3)点，SERVICE_B，第一次知道两半的信息，产品和价格！
在第(4)点，SERVICE_A得到响应的人也会得到两半。
我的问题是，SERVICE_B是否应该只将他的一半信息发回给SERVICE_A，让SERVICE_A重建整体？还是同时寄回？
SERVICE_B 仅发回价格。 SERVICE_A 谁发送请求 reconstruct someProduct = 1.2
{
"price": 1.2
}
或者 SERVICE_B 应该把所有东西都寄回去。
{
"product": "someProduct",
"price": 1.2
}
在我的示例中，我只使用了一个字段。但实际上，还有更多。这只是一个例子。
再次声明，这不是一个意见问题。我相信应该有一个基于性能、设计原则、微服务架构等方面的答案
谢谢
My question is, should SERVICE_B send back only his half of the information back to SERVICE_A and let SERVICE_A reconstruct the whole? Or send back both at the same time?
REST 中通常的回答是 SERVICE_B 将使用所请求资源的当前表示形式的副本来响应请求。
GET /price-list?product=someproduct
本质上，你是在问产品是否应该是代表的一部分，我的回答是：
- 当然可以，为什么不呢？
- 但你不必这样做。
如果 URI 中有“更多”项目，那么您可以挑选您想要的项目。
复习一下 Fielding 的论文 chapter 5，尤其是他关于缓存约束的评论可能会有所帮助。
The advantage of adding cache constraints is that they have the potential to partially or completely eliminate some interactions, improving efficiency, scalability, and user-perceived performance by reducing the average latency of a series of interactions.
换句话说，对于我们认为会缓慢变化的信息，效率来自减少往返次数，而不是来自减少响应的大小。
因此，您更有可能将额外的信息打包到响应中（假设缓存时间仍然令人满意）。
现在，如果您使用的不是 REST，而是具有更多 RPC 字符的设计 (SOAP/graphQL/gRPC)，那么答案可能会改变，因为“缓存”在通用时会失去很多功能组件无法利用它。
如果有额外的往返行程无论如何，保持较小的有效载荷是有意义的。
我，我会偏向于包括客户提供的信息，因为这为您提供了一种解决某些类型错误的方法。但这是一种“其他一切都平等”的立场。如果你需要小，如果你真的需要它，那么在引入故障排除支持时需要仔细考虑预算。
关于在拥有另一半信息时如何响应 restful 网络请求的小问题。
我想坚持认为这不是一个基于意见的问题，因为我相信应该有一个关于该做什么的最佳答案。
场景： 某些客户服务 SERVICE_A 是一种允许客户购买产品的服务。 然而，SERVICE_A只知道产品。也就是说，SERVICE_A不知道商品的价格，需要调用SERVICE_B来实时获取商品的价格。话虽如此，SERVICE_A，只知道一半的信息，只知道产品，不知道产品的价格。
客户将通过 SERVICE_A 前端 select 产品。客户不能去其他服务。然后 SERVICE_A 将通过 API 使用产品调用 SERVICE_B (1)。 像 :
{
"product": "someProduct"
}
然后，SERVICE_B 将收到请求 (2)，然后使用他知道的自己的算法计算价格 (3)。
完成后，SERVICE_B 会将价格 return 发送给 SERVICE_A (4)，后者现在拥有所有信息并可以将其显示给客户。
在第（1）点，SERVICE_A只知道了一半的信息。只有产品。
在第（2）点，SERVICE_B收到请求后也只知道一半的信息，只有产品。
在第(3)点，SERVICE_B，第一次知道两半的信息，产品和价格！
在第(4)点，SERVICE_A得到响应的人也会得到两半。
我的问题是，SERVICE_B是否应该只将他的一半信息发回给SERVICE_A，让SERVICE_A重建整体？还是同时寄回？
SERVICE_B 仅发回价格。 SERVICE_A 谁发送请求 reconstruct someProduct = 1.2
{
"price": 1.2
}
或者 SERVICE_B 应该把所有东西都寄回去。
{
"product": "someProduct",
"price": 1.2
}
在我的示例中，我只使用了一个字段。但实际上，还有更多。这只是一个例子。
再次声明，这不是一个意见问题。我相信应该有一个基于性能、设计原则、微服务架构等方面的答案
谢谢
My question is, should SERVICE_B send back only his half of the information back to SERVICE_A and let SERVICE_A reconstruct the whole? Or send back both at the same time?
REST 中通常的回答是 SERVICE_B 将使用所请求资源的当前表示形式的副本来响应请求。
GET /price-list?product=someproduct
本质上，你是在问产品是否应该是代表的一部分，我的回答是：
- 当然可以，为什么不呢？
- 但你不必这样做。
如果 URI 中有“更多”项目，那么您可以挑选您想要的项目。
复习一下 Fielding 的论文 chapter 5，尤其是他关于缓存约束的评论可能会有所帮助。
The advantage of adding cache constraints is that they have the potential to partially or completely eliminate some interactions, improving efficiency, scalability, and user-perceived performance by reducing the average latency of a series of interactions.
换句话说，对于我们认为会缓慢变化的信息，效率来自减少往返次数，而不是来自减少响应的大小。
因此，您更有可能将额外的信息打包到响应中（假设缓存时间仍然令人满意）。
现在，如果您使用的不是 REST，而是具有更多 RPC 字符的设计 (SOAP/graphQL/gRPC)，那么答案可能会改变，因为“缓存”在通用时会失去很多功能组件无法利用它。
如果有额外的往返行程无论如何，保持较小的有效载荷是有意义的。
我，我会偏向于包括客户提供的信息，因为这为您提供了一种解决某些类型错误的方法。但这是一种“其他一切都平等”的立场。如果你需要小，如果你真的需要它，那么在引入故障排除支持时需要仔细考虑预算。