HATEOASハイパーメディアのランタイム検出？

Question

私は、HATEOASがその時点でその応答（HAL、JSON-LDなど）としてアプリケーション内で実行できるすべてのアクションを送信することによって、アプリケーションの状態を表すことを理解しています。

たとえば、銀行のアカウントリソースを表示すると、口座を入金、引き出し、または閉じることができます（OPTIONSはUPDATEおよびDELETE動詞を返すことがあります）。

これらのリンク（消費側クライアントによる）のランタイム検出可能性の観点から、これについてどうすればよいでしょうか？

これらのリンクを送信する目的は、クライアントをサーバーから切り離し、応答でハイパーメディアによって状態を駆動する場合、開発者がアプリケーションにハードコードして何らかの意味をなす必要があります返される応答の

OPTIONS要求を送信することは、リソースの現在の状態と次に行うことができることを理解することですが、使用する実際のURIを検出するためには単純にCOOL URIとしてハードコードされますか？

Answer 1

表現力豊かで発見可能なハイパーメディアを作成しようとする試みには、先行技術がたくさんあります。あなたは確認することをお勧めします：

• http://json-ld.org/
• http://www.markus-lanthaler.com/hydra/

私は状態を決定または多分ステートメントを切り替えるために、特定のプロパティをチェックif文の多分シリーズを考えています。これは正しい経路ですか、あるいはハイパーメディア発見の手段がありますか？

私の現在の考えは、交渉の流れに沿ってあなたのアイデアを形作り、プロトコルに従うことです。ステートメントではなくステートマシンを考えてください。

初心者の方は、How To GET a Cup of Coffeeをご覧ください。

RESTBucksが提供するドキュメントのハイパーリンクは、クライアントがRESTBucksプロトコルのネゴシエーションを支援するように設計されています。クライアントがすでにプロトコルがモデルに焼き付けられていることをすでに理解しているという前提です。言い換えれば、クライアントはすでに、プロトコルの交渉がそれが​​3210に達することを許可することを理解しています。

もちろん、同じ目標を達成する複数のプロトコルが存在する可能性があります。例えば、RESTBucksは "Give Away Day Old Coffee"プロトコルもサポートすることができます。それぞれの存在を発表すると、クライアントはどちらが目標のより良い表現であるかを選択し、その経路に従うことが期待されます。

Answer 2

@VoicesOfUnreasonと同様に、HATEOASでは、URIは変更可能なように発見可能であり、文書化されていません。つまり、あなたのシステムの入り口になっていない限り（Cool URIs、クライアントによってハードコーディングできる唯一のものです）、あなたの残りの部分を進化させたい場合は、あまりにも多くのものを持つべきではありません将来のシステムのURI構造これは、実際には、RESTの機能の中で最も多くのものの1つです。

残りの非クールなURIについては、時間の経過と共に変更される可能性があります。また、APIドキュメントでは、実行時にハイパーメディアトラバーサルによって発見されるべきであるという事実を説明する必要があります。

Richardson's Maturity Model (level 3)を見ると、これはリンクが有効になる場所です。たとえば、トップレベルの/ api/version（/ 1）から、グループへのリンクがあることがわかります。ここでは、これがHAL Browserようなツールで見ることができる方法は次のとおりです。

ルート：

{ 
    "_links": { 
    "self": { 
     "href": "/api/root" 
    }, 
    "api:group-add": { 
     "href": "http://apiname:port/api/group" 
    }, 
    "api:group-search": { 
     "href": "http://apiname:port/api/group?pageNumber={pageNumber}&pageSize={pageSize}&sort={sort}" 
    }, 
    "api:group-by-id": { 
     "href": "http://apiname:port/api/group/id" (OR "href": "http://apiname:port/api/group?id={id}") 
    } 
    } 
} 

アドオンは単にそのエンドポイントにPOSTとなり、その後、あなたは2つのGETメソッドを持っていると思います。あなたが特定のグループ（例えば＃123）にドリルダウンしたら、次に

{ 
    "groups": [ 
     { 
     "id": 123, 
     "name": "Test Group" 
     }, 
     { 
     "id": 134, 
     "name": "Tennis squad" 
     } 
    ] 
} 

：このような何かを返すことができ

GET /api/group?pageNumber=0&pageSize=20&sort=asc

ここ

{ 
    "Id" : 123, 
    "Name" : "test", 
    "_links": { 
    "self": { 
     "href": "/api/group/1" (OR "/api/group?id=1") 
    }, 
    "edit": { 
     "href": "http://apiname:port/api/group/1" 
    }, 
    "api:delete": { 
     "href": "http://apiname:port/api/group/1" 
    }, 
    "api:items-query": { 
     "href": "http://apiname:port/api/bonus?groupId=1" 
    } 
    } 
} 

、編集します単純にPUTにする必要があります。また、DELETE（同じリンクでRESTのレベル2を参照）が必要です。アイテムに関しては、それらが単なるプロパティであればおそらく最もよく分かりますし、別のエンドポイントt;グループを取得している同じ呼び出しで返されるようにそれらを埋め込むことさえできます。

ここでの利点は、クライアントがリレーションシップ（およびリソース）URLを変更することがほとんど自由である一方で、クライアントはリレーションシップ（リンク）名（リソース構造/プロパティのほかに明らかに） 。