根本的にこれはドキュメントの問題ではなく、実装の問題です。
@avdi が数年前にこれを提起しており、適切なバージョン管理された JSON/REST API を、一貫したパラメータとデータ形状で提供することが正しい進路であるという広範な内部コンセンサスがあります。
現在、私たちが提供している API は内部 API です。これは 100% 完全で網羅的ですが、扱いにくく形状が変化します。返される形状とエンドポイントはすべて、クライアントサイドの Ember アプリを駆動するために最適化されています。数ヶ月かけて進化し形状が変わるため、ミッションクリティカルなタスクに依存するのは困難です。それに基づいた構築は、必要以上に複雑です。
まったく新しいコントローラーとルートのセットは、ここで安定性の問題を解決し、REST API に適した形状を返すことを可能にします。たとえば：
/api/v0/topic/1234.json は、より「一般的な API の実践と一貫した」形状を返すことができます。
私たちのトピック JSON には、あまりにも多くの非常に複雑な「Ember クライアント専用の懸念事項」があります。
timeline_lookup、post_stream、tags_descriptions など…など…
とはいえ、これは着手するには大規模なプロジェクトであり、ロジックの重複を避けるために多くの内部再設計が必要になります。さらに、プラグインはこれをさらに複雑にします。なぜなら、それらは多くの内部動作の形状を変更し、API でも反映する必要があるからです。（assign はこれらの形状にどのような影響を与えますか？）
この冒険に着手することは確かに見えますが、近い将来ではありません。