从根本上说，这不是一个文档问题，而是一个实现问题。
@avdi 多年前就提出了这个问题，并且内部普遍认为正确的解决方案是建立一个拥有统一参数和数据结构的、经过版本控制的 JSON/REST API。
目前，我们提供的 API 是我们的内部 API。它 100% 完整且详尽，但它使用起来很麻烦，并且数据结构会发生变化。它返回的数据结构和端点都是为驱动客户端 Ember 应用而优化的。随着时间的推移，它会不断演变和改变结构，这使得依赖它来完成关键任务变得很棘手。在此基础上进行开发比实际需要更复杂。
一套全新的控制器和路由将解决这里的稳定性问题，并允许我们返回更适合 REST API 的数据结构。例如：
/api/v0/topic/1234.json 可以返回一个“与通用 API 实践一致”的结构。
我们的 topic json 中有太多非常复杂的“仅限 Ember 客户端的考虑因素”：
timeline_lookup、post_stream、tags_descriptions 等等……
话虽如此，这是一个巨大的项目，我们需要大量的内部重新设计，以确保我们不会重复逻辑。此外，插件使这个问题更加复杂，因为它们会重塑许多内部行为，而这些行为需要在 API 中得到反映。（assign 对这些结构有什么影响？）
我当然认为我们会着手进行这项工作，但不会在不久的将来。