私はRESTの発見可能性に関連する概念を明確にしようとしています。つまり、RESTfulサービスのHATEOAS制約を満たすかどうかは、URIが発見可能であり、文書化されていないため、URIを変更できることを意味します。
これは、クールなURIの概念に従わないようです。URIが変更されないという事実です。また、Web自体のモデル（RESTは基本的に完全に適合するはずです）とは多少不一致です-URLはブックマーク可能であり、変更されることはありません。また、URLを習得すると、直接アクセスして実行できます。ルートを調べて毎回発見する必要はありません。
これに関するフィードバックは大歓迎です。
Cool URIの場合、いいえ。変更しないでください。これらは、システムへのエントリポイントです。ただし、将来的にシステムの残りのURI構造を進化させる機能が必要な場合は、それらをほとんど使用しないでください。
Cool以外のURIの場合、実際には時間の経過とともに変化する可能性があります。私は最近、このトピックに関するブログ投稿を書きました。これは、時間の経過とともにシステムを進化させることができるRESTの機能が非常に役立つためです。
APIドキュメントに、システム内の少数のCool URIのみをクライアントがハードコーディングする必要があり、その他のURIは実行時にハイパーメディアトラバーサルを介して検出する必要があるという事実が明記されていることを確認してください。それらをCポインタアドレスのように考えてください。ポインタ変数の16進値が何であるかは誰も気にしませんが、メモリ内の有効な場所を指すようにしたいのは確かです。非クールURIについても同じことが言えます。それらの構造は重要ではありませんが、サーバーとの会話を通じて実行時に取得されたという事実により、それらは有効になります。
ドキュメントが必要です。MediaTypesとLinkRelationsは結合点であり、クライアントとサーバーの両方がそれを理解する必要があります。そのため、HTML、ATOM、RSSには標準があります。
ランタイム機能に関しては、ドキュメントがないことがわかります。Yahooのホームページに何があるのかを知る必要はありません。同じように、私のサービスのクライアントは、私がリリースする新機能について知る必要はありません。彼らはリンクが存在することを見つけ、リンク関係を使用してそれが何をするかを見ることができます。
したがって、ドキュメントは使用される標準とプロトコルに関するものですが、アプリケーション自体がどのように機能するかについては説明していません。