問題タブ [hypermedia]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
wcf - WCF を使用した REST ハイパーメディアの実装
WCF ベースの REST サービスがあり、それにハイパーメディア サポートを追加する予定です。現在、データ コントラクトをシリアル化してサービス応答を構築するために WCF に依存しています。ハイパーメディアが表示されるようになったので、作成する XML 応答にハイパーメディア リンクを挿入するように WCF に指示する方法が必要です。私の質問は、どうすればいいですか?
1 つの方法は、データ コントラクトを変更して、上記のリンクをデータ メンバーとして含めることです。その後、WCF はそれらを自動的にシリアル化できます。しかし、それはベストプラクティスですか?それとも、WCF のシリアル化プロセスを傍受し、その時点でこれらのリンクを追加する方がよいでしょうか? または、他のより適切な代替手段はありますか?
authentication - ハイパーメディア (ReST) SOA: 一貫したサービスレベル認証のための優れた設計?
私は現在、SOA ソリューションを開発しています。このアーキテクチャでは、アーキテクチャ内の各サービスが安全で認証されたハイパーメディア リソースです (実際のハイパーメディアのように、きれいな URL を持つ RPC ではありません)。
顧客向け、社内向け、および顧客が構築したアプリケーションは、このアーキテクチャの上に構築されます (ここでは何も珍しいことではありません)。ユーザー識別と資格情報管理の要件が大きく異なる可能性があるため、アプリケーション間で共通の認証パターンが存在するとは想定できません。
したがって、アーキテクチャ内のサービスは別の認証スキームを使用する必要があります。理想的には、これはサービス (HMAC など) 間で完全に一貫しており、可能な限り多くのクライアント/サーバー モジュールを再利用できます。
私の質問は次のとおりです。分離されたサービス全体で一貫した認証と資格情報管理を提供するための共通パターンはありますか? もしそうなら、それは何ですか?
私はいくつかのアイデアを思いつきましたが、より経験豊富なエンジニアからの意見をいただければ幸いです。
1)各サービスは、個別ではあるが機械的に同一の認証インターフェイスを公開し、独自の資格情報管理を担当します。
2) 1)と同様ですが、資格情報管理を共有します。1)のように、アーキテクチャ内のサービスごとに個別の認証インターフェイスが引き続き公開されますが、基礎となるデータ メディアは共有されます。
3)単一の共有認証サービスがあり、それ自体と他のすべてのサービスの認証と資格情報管理を担当します。
アイデア2)が最も魅力的だと思いますが、もう少し改良が必要です。ここで完全に間違った方向に進んでいない限り。
適切と思われる限り、批判/提案してください。もちろん、これは設計に関するものであり、実装に関するものではないことに注意してください。現時点では、フレームワーク/ミドルウェア/プロトコル XYZ には興味がありません。
散文の謝罪、そして読んでくれてありがとう。
api - カスタムメディアタイプの関係の粒度と精度をリンクしますか?
私は、RESTful API 用のカスタム メディア タイプを設計している最中であり、いくつかの「標準」リンク関係のタイプとセマンティックな意味を調査して、私の設計にある程度の操縦を与えました。
問題を示すために、標準の読み取り、変更、削除メソッドを実行できるリソースがあり、GET、PUT、および DELETE の HTTP イディオムをそれぞれ使用してこれらのメソッドを実装するとします。
RFC5023で定義されているように、「編集」リンク関係 ( IANA リンク レジストリから) を合理的に (再) 使用できます。
"..."edit" の値は、href 属性の値が編集可能なメンバー エントリの IRI であることを指定します。atom:entry 内に表示される場合、href IRI を使用してリソースを取得、更新、および削除できます。そのエントリによって表される....」
このようにして、ユーザーエージェントは、「編集」関係を持つリンクがリソースの GET、PUT、および DELETE を許可することを理解できます。
ただし、ここに問題があります。リソースが GET 操作と DELETE 操作のみをサポートするようにリソースの状態が編集された場合、「編集」関係は正確ではなくなります。
精度を維持するために、i) オプション A: GET と DELETE のみをサポートする別の (複合) リンク関係を指定するか、または ii) オプション B: 可能な状態転送ごとに個別のリンクを指定し、適切なリンクを使用して示す必要があります。許可された状態遷移。後者のアプローチは正確ですが、過度に冗長に見えます。
別の方法として、(オプション C) 「編集」関係をそのままにして、精度の欠如を受け入れることもできます。つまり、リンクは GET、PUT、DELETE セマンティクスを伝達しますが、PUT を試みるユーザー エージェントは HTTP エラーに遭遇します。 405 - メソッドは許可されていません。ただし、サポートされていない状態遷移をクライアントに暗示するため、このアプローチにも満足していません。
要約すると、問題は、リンク関係の一般性と精度のバランスをとる最も賢明な方法は何かということです。
rest - 本当にRESTfulなサービスの実例
フィールディングの論文(コンテンツネゴシエーション、ハイパーメディアなど)に関して本当に100%RESTfulな実際のWebサービスはありますか?RESTをよりよく理解し、Restfulieのような自動化されたクライアントから使用できるものが必要です。私がこれまでに遭遇したRESTfulであると主張されているものはすべて、実際にはRPCまたはHTTPCRUDのいずれかであるように思われます。
java - Java Jersey 宣言型ハイパーリンク @Ref アノテーションの使用
Jersey 1.12 ドキュメントの第 6 章 (宣言型ハイパーリンク) で提供されている例を拡張しようとしましたが、@Ref アノテーションの使用に関して壁にぶつかったようです。
私のコードは次のとおりです。
これは、Widgets コレクション オブジェクトのインスタンスに対して生成された URL に対しては正常に機能します。
ただし、コレクション内のウィジェット インスタンスの ID を各ウィジェットの URL に追加する方法を知りたいです。したがって、生成される URI は次のようになります。
Widget クラス内でパス値全体をハードコードし始めることなく、Ref アノテーションを使用してこれを達成する方法を見つけることができないようです。これは、可能であれば避けたいと思います。
これを達成する標準的な方法はありますか?
rest - RESTful(ハイパーメディア)APIのクライアントの作成
私はここ数日、「本物の」RESTful APIを読んでいますが、それが何であるかについてはもうすぐだと思います。
しかし、私がつまずいたことの1つは、「実際の」ハイパーメディアAPIのクライアントをどのように作成するかを想像することすらできないということです。
私が読んだ例のほとんどはブラウザとスパイダーについて話しますが、それは特に役に立ちません。1つは人間主導で「インテリジェント」であり、もう1つは愚かで「ランダム」です。現状では、クライアントを機能させるにはAIを学ぶ必要があるという印象を受けます。
私にははっきりしないことの1つは、クライアントが特定のリンクで使用する動詞をどのように知っているかということです。これは、URIの「rel」タイプに暗黙的に含まれていますか?別の方法(ここを読んでください)は、xhtmlを使用し、フォームを解析して投稿できるクライアントを持っているようです。
リンクが変更される可能性はどのくらいありますが、リンクへのルートは変更されませんか?周りにあるほとんどの例では、ルートとリンクは同じです。
例えば。Toni's CakeShopからケーキのリストを戻すクライアントを設定したい場合:
Toni'sがToni'sFoodShopになり、リンクがなるとどうなりhttp://tonis.com/desserts/cakes
ますか?
cakes
下位互換性のために、ルートに最初のリンクを保持しますか?そうでない場合は、「ルートに移動してケーキを探す」と言われたかわいそうな小さなエージェントを「リダイレクト」するにはどうすればよいでしょうか。
私は何が欠けていますか?
http - REST サービスを設計するときに、リクエストの本文コンテンツ タイプで使用されるカスタム メディア タイプ
独自のカスタム メディア タイプ形式 (application/vnd.myapp+xml など) を作成する場合、クライアントは本文コンテンツを送信するときに、カスタム メディア タイプで送信する必要がありますか?
たとえば、注文の表現を uri に PUT します。クライアントにはリンクなどのハイパーメディア コントロールが含まれないため、コンテンツは application/vnd.myapp+xml にする必要がありますか、それとも単に xml にする必要がありますか?
ユーザーがそれを受け入れる場合、サーバーは常にカスタム メディア タイプで応答しますが (そうすべきです)、クライアントはそれを要求本文で使用する必要がありますか?
rest - バックボーンでハイパーメディア (REST) API を操作する
RESTful (できれば) API と通信する Backbone.js SPA を構築中。ハイパーメディアを使用してリソースをリンクし、リソースを中心に API を設計しようとしました。Backbone での実装を開始すると、Backbone で真のハイパーメディアを実現するのは適切ではない可能性があることに気付き始めています。
主な問題は、パスを事前に宣言したいバックボーン ルーターです。優れたハイパーメディア API では、リソース URI をクライアントにハードコーディングしないでください。これにより、新しい機能を追加したり、リソースの場所を (あえぎ) 変更したりする際の柔軟性が確保されます。
クライアント レベルのPage Resourcesを API レベルのObject Resourcesから分離するというアイデアで遊んでいます。これがおかしいと誰かが叫ぶ。基本的に、これはバックボーン アプリ (個別のページを考えてください) 内のリソースへのルートを定義することを意味し、1 つ以上の API レベルのリソースを取得します。
これは、いくつかの興味深い質問につながります。
これも良い考えですか?ルートが 1 対 1 になるように、アプリ内で API レベルのリソース URI を再利用するために最善を尽くすべきでしょうか。
- ページとapi オブジェクトは同じリソースの異なる表現にすぎないことは理解していますが、ほとんどの場合、ページは複数のリソースの複合体です。または、私はただクレイジーです:)
一連のナビゲーションの途中でページが更新されるとどうなりますか。API レベルのリソースが同じでない場合、それらの場所を知るにはどうすればよいですか?
RESTful な設計は、物事を前もって知ることよりも発見を重視しているように私には思えます。これを仮定するのは正しいですか?これがコードのダウンロードのすべてですか? 私が正しい方向に進んでいる場合、誰かが私にさらに読むように指示できますか.
ほとんどのリソースは読み取り専用であるため、GET 動詞のみを使用しますが、POST/PUT を使用するシナリオがいくつかあります (DELETE は実際にはこの特定のクライアントのドメインにはありません。完全に配置されています)。
*私は決して REST の達人ではありません。私はまだ学習過程にあるので、完全にベースから外れていることを遠慮なく言ってください。感情が傷つくことはありません。
編集:
私は、SPA との関係で、コードのダウンロードについてもっと考えてきました。さらにいくつかのオプション:
動的に読み込まれる「API」リソースまたは同様のリソース URI を定義します (コードのダウンロード)。次に例を示します。
/li>「ルート」リソース uri をルートとして使用して、リソースをナビゲートするときにルートを動的に定義します。これは Backbone.Router.route で可能だと思いますが、オンザフライで実行できるかどうかはわかりません。誰もこれを試しましたか?
rest - バックボーン コレクション、REST、およびベア アレイ
Backbone では、コレクション リソースがベア アレイを返すことが奨励されているようです。これは、Rails の実行モデルによって推進されているように思われますが、これは何かを実行する正当な理由にはなりません。これにはいくつかの問題があります。
- 多くの場合、「コレクション」リソースには、その周りのコンテキストも必要です。少なくとも、リソースの URI を応答に含めるという規則が気に入っています。ページング、小計 (たとえば、ショッピング カート内) などの他のことは、コレクションが「むき出し」になることはめったにないことを意味します。
- ベア アレイにはおそらくセキュリティ上の問題があります。いくつかの場所でこれを聞いたことがありますが、それを確認するにはいくつかの参照が必要です.
一方で、「そのままの」配列が API をより自然にする方法は次のようにわかります。
- コレクション内の各オブジェクトの形式は、そのコレクション内のオブジェクトを作成/更新するときの形式と同じになる傾向があります。
- 「コレクション」は、アイテムのコレクションという概念に意味的によく対応しています。
免責事項: ここでの前提は完全に間違っている可能性があります。REST は、HTTP 動詞や JSON よりもはるかに優れていることを認識しています。
c# - Web API でハイパーメディア リンクを生成する
他の人が Web API のハイパーメディア リンクを生成する問題にどのように対処したか知りたいです。具体的には、ASP.NET Web API を使用しており、操作でハイパーメディア関連の型を返すか、リソース自体を返すか、パイプラインの後半でハイパーメディアを処理するかで迷っています。つまり、人々は次のようなことをする傾向がありますか?
またはもっと似たようなもの
そして、ハイパーメディア リンクを HttpOperationHandler またはカスタム フォーマッタなどに追加しますか?
アプローチが 2 に似ている場合、生成するリンクをどのように知るのでしょうか? すべての Order オブジェクトに対して生成される標準的なリンクのセットがあるだけですか? OrdersController のさまざまな操作を装飾する属性?