RESTの検出可能性とHATEOASはURIを変更できることを暗示していますか?

私は、RESTの発見可能性に関連する概念を明確にしようとしています。つまり、RESTfulなサービスのHATEOAS制約を満たすかどうかは、URIが検出可能であり、文書化されていないため変更できることを意味します。

これは、クールなURI の概念に従わないように思われます。これは、今まで変わったことはありません。また、Web自体のモデル(RESTは本質的に完璧にフィットするはずです)には多少の違いがあります.URLはブックマーク可能で変更されることはないという事実と、一度学習すれば直に行くことができますルートを通過して毎回それを発見する必要はありません。

これに関するフィードバックは高く評価されます。

9

2 答え

クールなURIのために、あなたはそれらを今までに変更すべきではありません。それらはあなたのシステムへの入り口です。しかし、将来的にシステムのURI構造の残りの部分を発展させたい場合は、それらのうちのほんのわずかなものしか持っていないはずです。

クールでないURIの場合、時間の経過とともに変化する可能性があります。私は最近、このトピックに関するブログ投稿を書いています。これは、RESTの時間をかけて私のシステムを進化させて信じられないほど役に立つようにする能力。

APIドキュメントでは、システム内のいくつかのクールなURIだけがクライアントによってハードコーディングされるべきであり、その他のURIはハイパーメディアトラバーサルを通して実行時に発見されるべきであるという事実を説明してください。それらはCのポインタアドレスのように考えてください。誰もポインタ変数の16進値が何であるか気にすることはありませんが、メモリ内の有効な場所を指すようにしたいと確信しています。あなたの非クールなURIでも同じですが、その構造は重要ではありませんが、サーバとの会話を通じて実行時に取得されたという事実が有効になります。

6
追加された
早速のご返事ありがとうございます。私はこの記事を読んだことがありますが、いくつかの点ではまだ明確ではありません。まず、APIのバージョン管理は何ですか?第二に、どんなドキュメンテーションがあるべきか?私の理解では、純粋なREST実装では、ほとんどゼロのドキュメントがあるでしょう。そのような徹底的な変更のために、クールなURLだけを使用し、異なるバージョンのAPIを使用する方が良いでしょうか?
追加された 著者 Eugen,
実用的な観点から見ると意味がある。しかし私は、妥協する必要が生じる前に、純粋なRESTfulな実装についてもっと考えていました。バージョニングと実践的なアプローチに関連して、私は実際に多数のクライアントによって消費されるAPIの実際的な体験に興味があります。実際に変更することはできますか?実際には私の考えはできないということです。特に、クールURLを維持することに他の利点があるという事実を考慮して、バージョン管理だけが実行可能な方法です。興味深いフィードバックをありがとう。
追加された 著者 Eugen,
URI構造の互換性を維持するためだけにAPIをバージョン管理すると、Webサービスの各バージョンごとにWSDLを持つことと同じ問題が発生します。サービスを進化させることはなく、毎回新しいバージョンを追加しますテストし、維持し、文書化する必要があります。それを行い、RESTの大きな利点であるあなたの「契約」のダイナミックな進化と、クライアントとサーバーの素晴らしい分離を解きましょう。
追加された 著者 Brian Kelly,
ドキュメンテーションがないことについては、ソフトウェア世界全体がRESTの専門知識を開発したときには、それは完璧な意味合いがあります。あなたのAPIを使用したいと思う初心者がいつもありますし、彼らに働かせないものは私には意味がありません。確かに、RESTのエキスパートが座っていると思うかもしれませんが、それは私たちが住んでいる世界ではありません。メディアの種類と各リソースのセマンティクスを文書化し、どのように構築されたクライアントを構築する必要があるかを示すサンプルコードを提供します。あなたは大丈夫でしょう。
追加された 著者 Brian Kelly,
私はURIのバージョニングがなくても進化したRESTfulなAPIは見ていませんでした。それは、ほとんどのプログラマーがWSDLやCORBA IDLなどの技術で育てた「契約優先」の考え方に惑わされているからです。 RESTでその考え方から離れていくことが可能で、私も同じことをやろうと勧めています。
追加された 著者 Brian Kelly,

ドキュメントが必要です。 MediaTypesとLink Relationsは結合ポイントであり、クライアントとサーバーの両方がそれを理解しなければなりません。そのため、HTML、ATOM、RSSには標準があります。

ランタイム機能に関しては、ドキュメントがないことがわかります。 YahooがYahooのホームページを知る必要はありません。私はそれを発見することができるからです。私のサービスのクライアントは、私がリリースする新機能について知る必要はありません。彼らはリンクが存在するのを見つけて、それが何をしているか見るためにリンク関係を使うことができます。

したがって、ドキュメントは、使用される標準およびプロトコルの周りにありますが、アプリケーション自体がどのように機能するのかはわかりません

0
追加された