問題タブ [hateoas]

RESTAPIを使用してWebサービスを構築することに興味があります。私はHATEOASについて読んでいますが、多くの例では、人間がWebをサーフィンするときに行うことと比較することで概念を説明しています。これは私に考えさせられます、それが人間と機械の両方で簡単に使用できるような方法でREST APIを構築してみませんか？

たとえば、ウィジェットの内部モデルがあり、このウィジェットには部品番号や価格などのプロパティがあります。マシンがウィジェットのリストを要求すると、JSON表現を返すことができます。

人間が自分のWebブラウザーを介して同じリストを要求すると、同じ内部モデルを取得し、それに異なるビューを適用してHTML応答を生成できるはずです。（もちろん、ヘッダーやフッターなどの他のページ要素でHTML応答を装飾します）

これは賢明なデザインですか？なぜまたはなぜそうではないのですか？実際にやっている人気サイトはありますか？

私が目にする最大の欠点は、ユーザーがリソースを削除する明確な方法がないことです。私のユースケースでは、ユーザーがリソースを変更または削除できるようにするつもりはないので、これは大したことではありませんが、一般的にはどのように処理できますか？

私は最近SO でこのディスカッションを読んでいて、すべてのアプリケーションが REST ベースのアーキテクチャに適しているわけではないというコメントがありました。
ここで言う「REST ベースのアーキテクチャ」とは、RESTful apis + HATEOAS の全体を指します。Web 上のほとんどの例は「コーヒー ショップ」の例を参照しており、注文の作成 --> 更新/確認 --> 支払い --> 配達の受け取りというワークフローを通じて、Hateoas の部分を強調しています。したがって、REST は顕著な状態遷移を持つアプリに最も適していますか、それとも他の種類のアプリにも同様に適していますか? おそらく、REST を機能させるには状態遷移の観点からもっと考える必要があります。

HATEOASパラダイムでは、REST応答のリンクは、アクションまたはリソースを意味しますか？タイプドロップダウンのある注文フォームがあります。一部の詳細オプションフィールドは、それらの選択に基づいてフォームに読み込まれます。

HATEOASパラダイムに従うと、クライアントは、これらの追加フィールドをどこからロードするかを知っている、または推測することを期待されるべきではありません。したがって、提供されたすべてのオプションに1つのリンクを含めました。リンクオブジェクトのrel属性は、リンクの意図に関するある種のドキュメントを提供することになっています。これは正しい実装ですか？

ネット上で利用できる人気のあるコーヒーショップの例（Ian Robinsonの講演とInfoQの記事）では、リンクを使用して次に利用可能な状態遷移を識別します。これらは精神的に同等ですか？

Web が機能する理由は、各 Web サイトでバイナリ依存関係を取得する必要がないためです。おそらく、Flash と Silverlight が推奨されないのと同じ理由です。カスタム SDK を使用して REST Web サービスを利用することは、プラグインを使用してコンテンツを表示することと同義ですか?

既存のRestfulWebサービスを可能な限りHATEOSに変換した場合の潜在的なメリットについて多くのことを読んでいます。次の有効な利用可能なアクションを記憶する際の消費者の負担を軽減するために、ペイロードにリンクを提供することの重要性を理解しています。ただし、実際にRestfulWebサービスの利用者にどのように役立つかについて頭を悩ませているようには思えません。

説明のために、コーヒーの注文についてのRestInPracticeの本からこの例を取り上げます。-

基本的に、これにより、消費者は<link>タグで定義された支払いを行うことができます。ただし、実際には、コンシューマーは、そのWebサービス呼び出しのすべてのセマンティクス、たとえば、使用するメソッド（POSTまたはPUT）、支払いを行うためにペイロードで使用する要求パラメーターなどを知る必要があります。 ..言い換えると、コンシューマーは、このWebサービスを正常に呼び出す方法を知るためにWADLドキュメントに依存する必要があります。これらのタグは、すべてが1つの特定のアイテムに対してGETを使用している場合、おそらくより意味があります。そうでなければ、ここでリンクを定義することにあまりメリットはありません...消費者が次に呼び出すことができるアクションを知っているという事実を除けば、WADLを参照して正しく呼び出す方法を決定します。

<link>私の次の懸念は、すべてのタグで非常に重いペイロードになってしまう可能性です。たとえば、/ projects / 1 / usersのGETが、プロジェクト1に属するすべてのユーザー情報を返す場合、次のタグが付けられると思います。-

プロジェクトにたとえば500ユーザーが含まれている場合、ペイロードに500ユーザーリンクが含まれていませんか？それ以外の場合、この状況を処理するためにWebサービスを再設計するための最良のアプローチは何ですか？それとも、これは現実の世界で受け入れられますか？

どんな考えや提案もここで大歓迎です。ありがとうございました。

現在、REST Http API を設計しています。(HATEOAS を使用して、クライアントを「シンプル」にし、API に何をすべきかを指示させる代わりに、クライアントが複雑なことをするのを避けるため...)

アプリの社会的特性により、アプリケーションとやり取りするには、ユーザーを認証する必要があり、各ユーザーはデータの「ビュー」がわずかに異なります。例としてツイッターを取り上げます。誰にとっても簡単です。

ユーザーを認証するには、簡単な OAuth を使用します。

したがって、クライアント (ios アプリ...) では、ランダムなユーザーがユーザーのリストを表示する可能性があります。

また、別のユーザーは次のように表示される可能性があります。

これを実現するための最初の解決策は、クライアント (oauth 用語では iphone/web/etc アプリ) が、認証されたユーザーがフォローしているすべてのユーザーのリストを取得し、クライアントがリストを表示するたびにそれぞれを比較することです。 「フォローしていない」または「フォロー中」を表示する必要があるかどうかを知るために、フォローしているユーザーのリストを持つユーザー。

要求/応答は次のようになります。

と

これはかなり、ステートレスのようです。良い。

ここで、クライアント開発者の作業を楽にし、認証されたユーザーに対する各ユーザーの関係をユーザー リストの応答に直接埋め込みたい場合はどうすればよいでしょうか。

だから、質問：

• 「ステートレス」を破るように見えますが、本当にRESTステートレス制約を破っていますか?
• 次に、API がこれを行うのは良い習慣だと思いますか?それとも悪い習慣だと思いますか?

とhttp://example.com/fooのhttp://example.com/bar両方が同じリソースを表し、サーバーが 2 つを区別しない場合はどうなるでしょうか? アプリケーション状態のエンジン (HATEOAS に続く) を形成するドキュメント内でそれらを交換可能に使用して/bar、あるコンテキストと/foo他のコンテキストで表示されるようにするとどうなるでしょうか?

これはRESTfulですか？

これの潜在的な利点の 1 つは、記述子を URI に添付することです。たとえばhttp://example.com/article/30204/The-Quick-Brown-Fox、ブックマーク、検索エンジンのクエリ、および一般的には、URI を見るだけで URI を認識できる可能性があります。

RESTful Web サービスのリソース モデルを正式に指定する必要があり、仕様言語として XML スキーマを検討しています。理想的には、このリソース モデルは HATEOAS スタイルのクライアント開発を促進します。いくつかの質問：

1) Web リソースを正式に指定するには、XML スキーマが最適なオプションですか? 2) 各リソースをカスタム メディア タイプとして識別する必要がありますか? 3) リソースのリンク関係のセットをそのスキーマ仕様の一部として定義することは可能ですか?

ありがとう、キャメロン。

RESTful インターフェイスの設計に関するこの優れたプレゼンテーションによると、バージョン管理を実装するための推奨される方法は、次のようなものを使用して Accept-header を利用することです。

これは XML コンテンツ タイプに対しては完全に機能しますが、JSON に相当するものをバージョン管理するために同じスキームを使用することは可能ですか?

つまり、次のことを求めることは可能ですか。

応答は次のようになります。

および同等の JSON (一種):

HATEAOSの規約に従うようにしています。回答ごとに、別のページへのリンクを提供します。

次のページ (レコードのページング用) へのリンクを提供できることを理解しています。私の質問は、一般的なヘッダーとフッター (サインイン/アウト、ナビゲーション バー、一般的な情報 - 私についてなど) へのリンクを提供する必要がありますか?