假设有两个（或多个）提供JSON的RESTful微服务。服务A存储用户信息（姓名、登录名、密码等），服务B存储发送给/来自该用户的消息（例如，sender_id、subject、body、rcpt_ids）。在/profile/{user_id}上响应的服务A可以返回：{id:1，name:'Bob'}，{id:2，name:'Alice'}，{id:3，name:'Sue'}等。在/user/{user_id}/messages上响应的服务B返回一个列表，其中包含那些针对{user_id}的消息，如下所示：{id:1，subj:'Hey'，body:'Lorem ipsum'，sender_id:2，rcpt_ids:[1,3]}，{id:2，subj:'Test'，body:'blah blah'，sender_id:3，rcpt_ids:[1]}。
客户端应用程序如何处理这些服务，以便将姓名显示而不是发送者/接收者ID？方法1：获取消息列表，然后开始为列在sender_id和rcpt_ids中的每个ID提取配置文件信息？这可能需要数百个请求，可能需要一段时间。相当幼稚和低效，并且可能无法扩展到复杂的应用程序。 方法2：获取消息列表，提取所有用户ID，并为所有相关用户单独进行批量请求...这假设存在这样的服务端点。在获取消息列表、提取用户ID、发送批量用户信息请求之间仍存在延迟，然后等待批量用户信息响应。
理想情况下，我想一次性提供完整的响应集（消息和用户信息）。我的研究将我带到了在服务层合并响应的方法...即API网关技术。
但是如何实现这一点呢？我可以获取消息列表，提取用户ID，在幕后进行调用并获取用户数据，合并结果集，然后提供这个最终结果...这在幕后有2个服务时可以正常工作...但是如果消息列表依赖于更多的服务怎么办？如果我需要根据二级（三级？）结果查询更多的服务，进一步解析这些响应，然后最终合并...这种疯狂会在哪里停止？这将如何影响响应时间？
我现在实际上创建了另一个“客户端”，将所有微服务响应组合成一个超级响应...这与上述方法1没有什么区别...除了在服务器级别。
客户端应用程序如何处理这些服务，以便将姓名显示而不是发送者/接收者ID？方法1：获取消息列表，然后开始为列在sender_id和rcpt_ids中的每个ID提取配置文件信息？这可能需要数百个请求，可能需要一段时间。相当幼稚和低效，并且可能无法扩展到复杂的应用程序。 方法2：获取消息列表，提取所有用户ID，并为所有相关用户单独进行批量请求...这假设存在这样的服务端点。在获取消息列表、提取用户ID、发送批量用户信息请求之间仍存在延迟，然后等待批量用户信息响应。
理想情况下，我想一次性提供完整的响应集（消息和用户信息）。我的研究将我带到了在服务层合并响应的方法...即API网关技术。
但是如何实现这一点呢？我可以获取消息列表，提取用户ID，在幕后进行调用并获取用户数据，合并结果集，然后提供这个最终结果...这在幕后有2个服务时可以正常工作...但是如果消息列表依赖于更多的服务怎么办？如果我需要根据二级（三级？）结果查询更多的服务，进一步解析这些响应，然后最终合并...这种疯狂会在哪里停止？这将如何影响响应时间？
我现在实际上创建了另一个“客户端”，将所有微服务响应组合成一个超级响应...这与上述方法1没有什么区别...除了在服务器级别。
这就是在"真实世界"中的做法吗？有什么见解吗？是否有任何基于这种API网关架构构建的开源项目我可以查看？
