1

APIにHATEOASを実装する方法（および実装する場合）に頭を悩ませようとしています。現在の状況に適したアクションのみをクライアントに提供するというコンセプトの 1 つが気に入っています。ただし、このアイデアを正しく実装しているかどうかはわかりません。

ステータスが変更可能なリソース タイプの注文があるとします。ステータスはさまざまです (処理中、承認済み、拒否済み、期限切れ、成功)。次に、次のjsonオブジェクトを作成する必要があります:

{
    ...
    "links": {
        "accept": "http://example.com/order/1/accept",
        "decline": "http://example.com/order/1/decline"
    }
}

それとも、ここで不要なアクションを作成していますか? 上記が正しい場合、PATCH または GET によってステータスを変更する必要がありますか? そして、それがパッチだったら、どうやって (ハイパーメディアの目的を破って) 知ることができるでしょうか?

編集：注文IDを追加するのを忘れました

4

1 に答える 1

7

ステータスが変更可能なリソース タイプの注文があるとします。ステータスはさまざまです (処理中、承認済み、拒否、期限切れ、成功)。

警告: あなたのドメインがたまたまドキュメント管理でない限り、リソースをドメインの概念と一致させようとすると、混乱する可能性があります。Jim Webberはこのことについて何年も前に警告しました。ほとんどの場合、リソースは統合ドメインの一部です。それらは、ドメイン モデルと対話するために使用される小さなデジタル紙です。

{
    ...
    "links": {
        "accept": "http://example.com/order/accept",
        "decline": "http://example.com/order/decline"
    }
}

ここでの基本的な考え方は問題ありません。クライアントが受け入れプロトコルを呼び出したい場合、クライアントはどのリンクを使用するかを知っています。拒否プロトコルについても同様です。それ以外の場合、クライアントは、リンクが利用できないため、実行しようとしてはならないことを知っています。たとえば、クライアントの目的が注文を期限切れにすることである場合、注文が行き詰まりに陥ったことがわかります。

ここでの URI のスペルは少し奇妙です。クライアントはスペルを気にする必要はありませんが、リクエストはステートレスでなければなりません。注文がリソースのタイプである場合、どの注文を受け入れる/拒否するかをどのように伝えていますか。

上記が正しい場合、PATCH または GET によってステータスを変更する必要がありますか?

ない。

GETは間違っています。リソースが GET をサポートしていることを宣伝することは、操作が安全であるという主張であるためです。つまり、中間コンポーネントが投機的にリンクをたどり、結果をプリロードしてクライアントの時間を節約できることを意味します。クライアントが下した決定を伝えるメッセージを理解している場合、やりたいことではありません

PATCHには 2 つの問題があります。まず、ドキュメント操作用に設計されています。アプリケーションがドキュメント データベースである場合、PATCH は 1 つまたは複数のスコープ変更を行うのに最適です。しかし、ビジネス モデルのプロキシ表現を扱うにはあまり適していません。クライアントがその意図をサーバーに伝える代わりに、クライアントはその意図が表現に与える副作用を伝え、サーバーはその副作用から意図を推測しようとします。

しかし、それを回避できる可能性があります。結局のところ、サポートするメディア タイプを選択できるため、クライアントの意図を表現できるタイプに制限される可能性があります。

2 番目の問題は、PATCH がべき等ではないことです。POST と同じ障害モードがあります。リクエストがサーバーによって確認されない場合、クライアントはリクエストを再試行しても安全かどうかをすぐに判断できません。

率直なアプローチは、編集を手書きのメモを誰かの受信トレイに入れることに似ていると考えることです。

注文 54321 を受け入れる必要があります。やり遂げてください。署名した、クライアント。

つまり、注文リソースを直接操作しようとしているのではなく、注文を操作するという副作用を持つメモを受信トレイに配信しています。クライアントは必要な変更を記述し、サーバーは変更を行います (または、サーバーに自律性を許可している場合は変更しません)。

このアプローチでは、PUT (べき等) または POST (そうでない) が適切です。実際には、新しいメッセージを inbox コレクションに追加しているので、そのイディオムを使用して適切な方法を選択できます。

そして、それがパッチだったら、どうやって (ハイパーメディアの目的を破って) 知ることができるでしょうか?

クライアントは、「リンク」プロパティでリンクを探すことをどのように知るでしょうか?

ブラウザーは、HTML ドキュメント内のリンクをどう処理するかをどのように認識していますか?

REST の答えは次のとおりです。メディア タイプ自体の設計に多大な労力を費やしたので、彼らは知っています。Web の場合、text/html メディア タイプの設計に多くの時間と労力が費やされたため、html を念頭に置いて設計されたクライアントは、その理解を共有するサーバーによって生成された表現を消費できます。クライアントとサーバーは互いに切り離されていますが、共通の基盤を共有しています。

HTML の場合、ほとんどの場合、メディア タイプはリンクに関連付けられた HTTP メソッドを定義します (フォームは例外であり、表現が制限されたセットからメソッドを指定できるようになります)。巨人の肩の上に立つ。

于 2016-09-12T23:03:02.120 に答える