HATEOAS（REST-architecture）の実際の例[終了]

誰もが気付いているかもしれませんが、実際には多くの偽/基本的なREST-APIがあります（HTTP-APIを実装し、アプリケーションの状態としてのハイパーテキスト要件に従わずにRESTと呼びます）。最初にRESTパラダイムを指定した男、ロイT.フィールディングの有名な怒りに）。

真のハイパーテキスト駆動型REST実装の実用的な例と、状態遷移に関連するアプリケーション固有のメディアタイプ定義を見つけることができませんでした。

そのような実装の公にアクセス可能な例はありますか？

コードを実行するという意味での実装ではありませんが、InfoQ の記事「コーヒーを1杯手に入れる方法」は本当に気に入っています。スターバックスでコーヒーをRESTfulプロトコルとして注文するプロセスについて説明します。これは、典型的な「すべてがリソースである」REST紹介記事を超えて、HATEOASに焦点を当てています。強くお勧めします。

いかが日クラウドAPI？はじめから：

APIは、URIスペースに特定の構造がないことを前提としています。開始点は、クラウド自体を識別する、クラウドサービスプロバイダーによって提供されるURIです。クラウドの表現には、クラウド内の他のリソースのURIと、それらに対して実行される可能性のある操作（仮想マシンのデプロイや起動など）のURIが含まれています。

裏話はまた、役に立つかもしれません。

Netflixには、リソースの一部としてリンクを含むHATEOASに基づくREST APIがあります。

Royの4番目のポイントで実際に対処されているSun Cloud APIのRESTfulnessではありません。

REST APIは、固定リソース名または階層（クライアントとサーバーの明らかな結合）を定義してはなりません。サーバーには、独自の名前空間を制御する自由が必要です。代わりに、サーバーがクライアントに適切なURIを構築する方法を指示できるようにします（HTMLフォームやURIテンプレートで行うなど）。メディアタイプとリンク関係内でこれらの指示を定義します。[ここでの障害は、RPCの機能的結合と同等のデータ指向のドメイン固有の標準など、帯域外情報のためにクライアントがリソース構造を想定していることを意味します]

例1定義された階層の固定リソース名：

Sun Cloud APIから：「... VDCの表現には、それに属するクラスターの表現が含まれ、各クラスター内のVMの表現も含まれます。」

例2ドメイン固有の標準などの帯域外情報：

クラウドリソースフィールド「uri」の「リソース通信メカニズム」がGETであることを知るには、wikiページのコンテンツ（帯域外情報）が必要です。

これは少し前に尋ねられたことに気づきましたが、簡単な例のために「適切な」REST APIフローのデモを試してみました。RESTに関するRoyのルールに従ってみました-おそらくそれは役立つかもしれません： RESTを使用したAPIの例