システム間インターフェースでこれをどのように行いますか? クライアントがhttp://my.server.orgのサーバーで注文を作成したいとします
http://my.server.org/nOなどではありませ
んか?
それは学びません。通常、マシン クライアントは「学習」できません。少なくとも、私たちはまだ Skynet の前です。それらを「教える」必要があります。
しかし重要なのは、彼らに URL を教えないことです。あなたは彼らに関係を教えます。
HTMLで考えてみてください...
<a rel="order" href="http://my.server.org/newOrder"/>
と
<a rel="order" href="http://my.server.org/nO"/>
rel は同じ "order" ですが、URL は違います。
「完璧な」世界では、システムには単一のエントリ ポイント (たとえば、http://my.server.org/ ) があり、クライアントはそこから、知る必要のあるすべての rel を見つけることができます。
実際には、多くのシステムには、クライアントが常にシステムのルートから開始する必要がないように、便宜上、クライアントが開始できるいくつかの「よく知られている」定義済みのエントリ ポイントがあります。これらのよく知られているエントリ ポイントには、これらの URL がすぐには変更されないというプロバイダーからの暗黙のコミットメントがあります。それらが長命であり、サーバーがそれらを非常にうまくサポートすること。
しかし、エントリ ポイントを通過すると、その背後にそのような約束がない URL が見つかる可能性があります。URL は 1 回限りの URL にすることができます。たとえば、負荷分散のために別のマシンに向けることができます。知るか。しかし、サービスの利用者としては、URL が何であるかは気にせず、関係だけを気にします。リレーションは、使用する URL の詳細を示します。
ハイパーメディア API のドキュメントには、クライアントが遭遇する各 rel に統一インターフェイスを適用する方法が説明されています。クライアントはそれを「直観」することもできず、教えなければなりません。
基本的に、クライアントが処理するペイロードで検出する、または検出する可能性のある関係をナビゲートする方法をクライアントに教えることが、クライアントがハイパーメディア API を操作する方法です。ペイロードには道を示す標識が含まれていますが、標識の行き先はサーバーによって指示されます。
マシン ツー マシンの世界での使用頻度については、おそらくそれほど多くはありません。ほとんどのシステムは、URL の変更が問題になるほど大きくなく、クライアントが非常に少ないため、クライアントを変更しても大きな負担にはなりません。したがって、ほとんどの場合、ハードコードを離れただけです。
しかし、最終的には、悪いクライアントが発生するだけです。悪いクライアントに対して REST システムができることは何もありません。とにかく、実行時にそれらを区別することはできません。