我目前正在开发一个前端应用程序，我需要在其中显示有关作者的信息。每个作者可以有多个子对象（例如书籍），并且我还需要显示有关兄弟对象的信息（例如与作者相关的出版商）。
这是我面临的挑战：
显示子对象：我可以使用 /authors 这样的端点轻松检索作者及其书籍，这似乎符合 RESTful 设计原则。
显示同级对象：但是，我不确定如何在不违反 REST 原则的情况下有效地包含同级对象，例如发布者（或不直接属于作者但在某些上下文中相关的任何其他相关数据）。
以下是我正在考虑的选项：
选项 1：在 /authors 端点中包含所有相关数据（作者、书籍和同级对象）。这种方法看起来很简单，但感觉它不符合 RESTful 设计，因为同级数据不是作者资源的直接一部分。此外，我担心有效负载大小可能会增加，这可能会影响性能。
选项 2：为每个作者进行单独的 API 调用，以从各自的端点获取同级数据。这可能会因多个网络请求而导致性能问题。
选项 3：实现后端换前端 (BFF) 模式，专门针对前端需求定制 API 响应，绕过严格的 REST 约定。然而，这种方法需要对我们当前的架构进行重大改变。
我正在寻找一种方法将同级添加到我的结果中，而不损害性能或增加设计此 API 的服务器/网络负载。如何构建 API 以高效检索子对象和同级对象，同时保持 RESTful 方法？是否有任何行业标准模式或策略来处理这种情况？
任何见解或建议将不胜感激！
在这个答案中，我假设您的目标是 1. 性能提高 2. 网络和负载减少
为了解决这两个问题，您需要为您的端点支持水合版本和非水合版本。
所以，作者和书籍都是端点核心逻辑的一部分，也就是说，所有使用都需要作者和书籍，但有时需要出版商（和其他实体），有时不需要。
因此，您可以为端点指定一个参数，该参数将列出 API 调用者想要进行水合的实体。一个示例值可能是
publisher,blublabli,category
因此，您可以使用分隔符（在本例中为
,确保返回的格式一致，最好在每个作者的对象内有一个水合实体数组，并且包含实体名称的键值对和该实体的水合对象数组.
这将使您 1. 当您要加载水合值时变得高效，因为您可以以最佳方式在引擎盖下构造内部事物，并根据需要选择性地加入某些表，2. 减少服务器负载和通过在不需要的地方不给兄弟姐妹补水来减少网络负载。
当然，您也可以实现一个端点来获取一本书的出版商，这也将有合法的用例。