在请求 2 中还有waitFor属性：这用于指示该子请求取决于前一个请求的响应。我们实际上可以看到，我们已经使用从请求1的响应中获得的值构造了2的uri，特别是书籍的uuid。最终，请求 1 发送至解耦路由器路径，该路径返回我们感兴趣的书籍 id，请求 2 发送至返回书籍数据的路径。
因此，总而言之，我们已经看到在我们的架构中，每个生态系统模块如何构建在前一个模块的基础上，并允许其功能日益定义和专业化。结果是一组易于配置、管理和高度可定制的 API，并且基于 JSON:API，易于通信和移植。
如果我们想进一步扩展项目的功能，在编写自定义代码之前，我们还有许多其他可用模块：JSON:API 搜索 API允许您使用与刚才看到的类似的方法对网站的搜索索引发出请求。
实体共享利用公开的 JSON:API 来允许同步两个 Drupal 站点的内容。
Commerce API通过利用 JSON:API 集成了 Drupal Commerce 所需的功能。
这个模块列表并不详尽，但它仍然是一个很好的起点，可以更完整地了解 Drupal 上的 JSON:API 生态系统。
最后的想法
在这里，我们重点关注 JSON:API，但这并不是可用于 新西兰电报数据 实现我们目的的唯一模块或生态系统。它是目前最完整且受支持的一种，但除了自定义代码之外，还有其他选项。
在 Drupal核心中，我们有另一个模块，RESTful Web Services，它在一段时间内是 JSON:API 的直接竞争对手，成为该用例的事实上的标准。 JSON:API 最终得以建立，主要是因为它的简单性能够覆盖大多数用例。 JSON：API 允许您公开网站上存在的所有实体，几乎不需要额外的工作，而 RESTful Web 服务需要更复杂的自定义配置，数据过滤的选项更有限且配置更复杂，对资源的请求更少与 JSON:API 相比，它是结构化的，并且只有在配置特定视图后才能公开集合。简而言之，这是一个很好的模块，但与 JSON:API 的简单性和灵活性相比，它有些落后。另一方面，对于特定的用例，例如具有自定义逻辑的操作或未严格链接到实体的操作，RESTful Web 服务提供了一个可以利用的当然更灵活的框架，但代价是总体复杂性更高。
另一方面， GraphQL的支持得益于contrib模块。因此，他并不是核心人物，而且在这三个人中，他是最晚到达现场的。总的来说，基于 GraphQL，它具有优秀的、文档齐全的规范，但有些东西不太灵活，例如写入操作和客户端内容过滤，而我们通过 JSON 的 Drupal 实现却发现这些事情非常简单：API。
然而，GraphQL 模块无疑是一个可行的选择，最初由 Dries Buytaert 本人大力赞助，即使目前与 Drupal 集成的支持和完整性尚无法与 JSON:API 生态系统竞争，而无需编写更多自定义内容代码。
观看 Headless Drupal 技术讲座
不想阅读全文？下面的视频是本文的有效替代方案。