2

HATEOAS 原則「クライアントは、サーバーによってハイパーメディア内で動的に識別されるアクションによってのみ状態遷移を行う」

今、私は単語動的に問題を抱えていますが、それはそこで最も重要な単語の 1 つだと思います。

API でパラメーターの 1 つをオプションから必須に変更した場合、クライアントを修正する必要があります。そうしないと、リクエストが失敗します。

要するに、HATEOAS が行うことは、サーバー側の開発者に、API を使用するすべてのクライアントを犠牲にして、API を自由に変更できる極端な自由を与えることだけです。

私はこれを言っているのは正しいですか、それともサーバーが採用しなければならないJSON以外のバージョニングや他のメディアタイプのようなものを見逃していますか?

4

3 に答える 3

2

API でパラメーターをオプションから必須に変更すると、その API のコンシューマーが中断されます。HATEOAS の原則に従う REST API であるということは、これを変更するものではありません。代わりに、互換性を維持したい場合は、そのような変更を避ける必要があります。古い API に対して記述されたクライアントによって行われた呼び出しまたはメッセージが引き続き期待どおりに機能することを確認します。

一方で、返される要素のセットが常に同一であると期待するようにクライアントを記述しないことも良い考えです。サーバーが提供することを選択した場合、サーバーによって提供される追加情報を無視できる必要があります。繰り返しますが、これは優れた API 設計です。

HATEOAS は問題ではありません。過度に厳格な API の期待が問題です。HATEOAS は、問題の解決策の一部にすぎません (クライアントが、サービスの状態モデルについて膨大な量を知る必要がなくなる可能性があるためです。たとえそれが必ずしも単純なものであるとは限りません)。

于 2013-02-05T16:02:09.917 に答える
1

Donal Fellows は良い答えを持っていますが、同じコインには別の側面もあります。HATEOAS の原則には、メッセージの形式についてそれ自体は何も言いません (REST の他の部分はそうです)。代わりに、それは基本的に、クライアントが帯域外で動作する URI を知ろうとすべきではないことを意味します。代わりに、サーバーは、ハイパーリンク (またはハイパーリンクを構成するフォーム/テンプレート) を介して、どの URI に関心があるかをクライアントに通知する必要があります。使い方：

  1. クライアントは状態 0 から開始します。
  2. クライアントは既知のリソースを要求します。
  3. サーバーの応答により、クライアントは新しい状態Nに移動します。応答コードとペイロードによっては、この時点で達成可能な状態が複数ある場合があります。
  4. 応答には、次の潜在的な状態のセットをバンドでクライアントに伝えるリンク (またはフォーム/テンプレート) が含まれます。
  5. クライアントは、URI でメソッドを発行することにより、次の状態のいずれかを選択します。

クライアントのアプリケーションのニーズが満たされるまで、状態N+1以降まで3 から 5 を繰り返します。

このように、サーバーは、クライアントを壊すことなく、状態Nから状態N+1にクライアントを移動する URI を自由に変更できます。

于 2013-02-05T17:41:54.940 に答える