REST発見可能性に関連する概念を明確にしようとしています。つまり、RESTfulサービスのHATEOAS制約を満たすかどうかは、URIが検出可能であり、文書化されていないため変更できることを意味します。RESTの検出機能とHATEOASは、URIを変更できることを意味しますか？
これは、Cool URIsのコンセプトに従わないように見えます - URIが変わらないという事実。また、Web自体のモデル（RESTは本質的に完璧にフィットするはずです）には多少の違いがあります.URLはブックマーク可能で変更されることはないという事実と、一度学習すれば直に行くことができますルートを通過して毎回それを発見する必要はありません。
これに関するフィードバックは高く評価されます。
クールなURIに関しては、あなたはそれらを今までに変更すべきではありません。それらはあなたのシステムへの入り口です。しかし、将来的にシステムのURI構造の残りの部分を発展させたい場合は、それらのうちのほんのわずかなものしか持っていないはずです。
クールでないURIの場合、は実際にはに変更できます。私は最近、このトピックについてblog postと書いています。なぜなら、私が時間の経過とともにシステムを進化させて信じられないほど役に立つようにするRESTの能力があるからです。
システムのいくつかのクールなURIだけがクライアントによってハードコードされるべきであり、実行時にハイパーメディアトラバーサルを介して他のURIが検出されるべきであるという事実をAPIドキュメントが綴っていることを確かめてください。それらはCのポインタアドレスのように考えてください。誰もポインタ変数の16進値が何であるか気にすることはありませんが、メモリ内の有効な場所を指すようにしたいと確信しています。あなたの非クールなURIでも同じですが、その構造は重要ではありませんが、サーバとの会話を通じて実行時に取得されたという事実が有効になります。
ドキュメントが必要です。 MediaTypesとLink Relationsは結合ポイントであり、クライアントとサーバーの両方がそれを理解しなければなりません。そのため、HTML、ATOM、RSSには標準があります。
ランタイム機能に関しては、ドキュメントがないことがわかります。 YahooがYahooのホームページを知る必要はありません。私はそれを発見することができるからです。私のサービスのクライアントは、私がリリースする新機能について知る必要はありません。彼らはリンクが存在するのを見つけて、それが何をしているか見るためにリンク関係を使うことができます。
ドキュメントは、使用される標準およびプロトコルの周りにありますが、アプリケーション自体がどのように機能するかについては記載されていません。
ありがとうございました。私はこの記事を読んだことがありますが、いくつかの点ではまだ明確ではありません。まず、APIのバージョン管理は何ですか？第二に、どんなドキュメンテーションがあるべきか？私の理解では、純粋なREST実装では、ほとんどゼロのドキュメントがあるでしょう。そのような徹底的な変更のために、クールなURLだけを使用し、異なるバージョンのAPIを使用する方が良いでしょうか？ – Eugen
URI構造の互換性を維持するためだけにAPIをバージョニングすると、Webサービスの各バージョンごとにWSDLがあることと同じ問題が発生します。サービスを進化させることはなく、毎回新しい（ほとんど複製された）バージョンを追加します。テストし、維持し、文書化する必要があります。それを行い、RESTの大きな利点であるあなたの「契約」のダイナミックな進化と、クライアントとサーバーの素晴らしい分離を切り分けてください。 –
そして、ドキュメントを持っていないとして、ソフトウェア世界全体がRESTの専門知識を開発したときには、それは完璧な意味を持っています。あなたのAPIを使用したいと思う初心者がいつもありますし、彼らに働かせないものは私には意味がありません。確かに、RESTのエキスパートが座っていて、それをすべて把握できるかもしれませんが、それは私たちが住んでいる世界ではありません。メディアタイプと各リソースのセマンティクスを文書化し、どのように構築されたクライアントが構築されるべきかを示すサンプルコードを提供してください。 –