【问题标题】:Web service design: should a rest api send back half or all information?Web 服务设计:rest api 应该发回一半还是全部信息?
【发布时间】:2021-02-15 14:16:44
【问题描述】:

关于在拥有另一半信息时如何响应宁静的网络请求的小问题。

我想坚持这不是一个基于意见的问题,因为我认为应该有一个关于做什么的最佳答案。

场景: 某些客户服务 SERVICE_A 是允许客户购买产品的某种服务。 但是,SERVICE_A 只知道产品。意思是,SERVICE_A不知道产品的价格,它需要调用SERVICE_B来实时获取产品的价格。话虽如此,SERVICE_A只知道一半的信息,只知道产品,不知道产品的价格。

客户将通过 SERVICE_A 前端选择产品。客户不能使用其他服务。然后 SERVICE_A 将通过 API 调用 SERVICE_B (1) 与产品。 类似:

{
    "product": "someProduct"
}

然后,SERVICE_B 将收到请求 (2),然后使用他自己知道的算法计算价格 (3)。

完成后,SERVICE_B 会将价格返回给 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 重构 someProduct = 1.2

{
    "price": 1.2
}

或者应该 SERVICE_B 将所有内容都发回。

{
    "product": "someProduct",
    "price": 1.2
}

在我的示例中,我只使用了一个字段。但实际上,还有更多。这只是一个例子。

同样,这不是意见问题。我相信应该有一个基于性能、设计原则、微服务架构等的答案。

谢谢

【问题讨论】:

  • SERVICE_A 和 SERVICE_B 是否存在单独存在的用例?如果是,则客户端调用 SERVICE_C,它协调调用 SERVICE_A 和 SERVICE_B,并返回组合结果。一般来说,尽量减少客户的闲聊。
  • 谢谢安德鲁! SERVICE_A 和 SERVICE_B 单独存在以回答这个特定的用例。客户必须致电 SERVICE_A,因为 SERVICE_A 将在前端进行产品选择和显示价格等...

标签: java json rest web-services


【解决方案1】:

我的问题是,SERVICE_B 是否应该只将他的一半信息发回给 SERVICE_A,让 SERVICE_A 重建整个信息?还是同时寄回?

REST 中的通常答案是 SERVICE_B 将使用其当前请求资源表示的副本来响应请求。

GET /price-list?product=someproduct

本质上,您是在问产品是否应该成为表示的一部分,我的回答是:

  • 当然,为什么不呢?
  • 但您不必这样做。

如果 URI 中有“更多”项目,那么您可以挑选您想要的项目。

查看菲尔丁论文的chapter 5 可能会有所帮助,尤其是他关于缓存约束的评论。

添加缓存约束的优势在于,它们有可能部分或完全消除某些交互,通过减少一系列交互的平均延迟来提高效率、可扩展性和用户感知的性能。

换句话说,对于我们认为将缓慢变化的信息,效率来自减少往返次数,而不是减少响应的大小。

因此,您更有可能将额外信息打包到响应中(假设缓存时间仍然令人满意)。


现在,如果您使用的是具有更多 RPC 字符(SOAP/graphQL/gRPC)的设计,而不是 REST,那么答案可能会改变,因为当通用组件无法实现时,“缓存”会失去很多功能充分利用它。

如果要进行额外的往返无论如何,保持有效载荷较小是有意义的。

我倾向于包含客户提供的信息,因为这为您提供了一种解决某些类型错误的方法。但这是一种“其他一切都平等”的立场。如果您需要少量,如果您真的需要,那么在引入故障排除支持时,您需要仔细考虑预算。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2020-12-16
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2021-06-25
    • 2021-02-22
    • 2015-06-23
    • 1970-01-01
    相关资源
    最近更新 更多