5

HATEOAS REST API に基づく Web アプリケーションでの URL (および各 URL に関連する状態) の処理に関するアドバイスを探しています。より具体的には、

  • Web アプリケーションの URL が REST API の URL と結合されないようにする方法
  • 単一のビューで複数のリソースを処理する方法

しかし、最初にもう少しコンテキストを提供させてください。

ハイパーメディア制約を使用して、REST レイヤーの上に Angular Web アプリケーションを構築しています。(注: HATEOAS よりも単に「ハイパーメディア (制約)」という用語を使用することを好みます)。

ハイパーメディアの制約によって指示されるように、アプリケーションでいつでも使用可能なアクションとリンクは、REST API によって提供されます。そのため、Web アプリケーションには、「ルート」を除いて、REST API のハードコードされた URL を含めないでください (その概念が REST API に実際に存在すると仮定します)。

一方、Web アプリケーションの各ページはブックマーク可能である必要があります。そのため、ブラックボックス アプリケーションを作成することはできません (単一の URL と、URL を変更せずにすべての状態変更が SPA で処理される)。これは、Web アプリケーションにも独自の URL 空間があり、何らかの方法で REST API の URL 空間にマップする必要があることを意味します。これはすでにハイパーメディアのアイデアと矛盾しています。

Angular アプリケーションでは、アプリケーションの状態を処理するために UI Router を使用します。これを機能させる方法は次のとおりです。

  • 状態のみを定義し、URL は定義しません
  • 現在の Web アプリケーション URL を対応する REST API URL にマップし、その REST URL に対応するリソースの表現を取得して、コントローラー ($stateParams 内) に渡す $urlRouterProvider.otherwise ハンドラーを定義しました。
  • コントローラーは、REST 呼び出し自体を (またはサービスを介して) 行った場合と同様に、データ (およびリンクとアクション) を表現で使用できます。

このアプローチにはいくつかの欠点があるため、これまでのところ非常に優れています (または実際にはそうではありません)。

  • Web アプリケーションの URL は REST API の URL にマップされるため、両方の URL スペースが結合されます。これは、ハイパーメディア制約を使用する際の基本的な前提の 1 つと矛盾します。つまり、REST API の URL は、Web アプリケーションを変更せずに変更することはできません。
  • $urlRouterProvider.otherwise ハンドラーでは、現在の Web アプリ URL の表現を取得します。しかし、場合によっては (UI ルーターのネストされた状態を使用して) 1 つのビューに 2 つのリソースがあります。たとえば、アイテムのリストと 1 つのアイテムの詳細です。ただし、URL は 1 つしかないため、アイテムの詳細の表現のみが取得され、アイテムのリストは空のままです。

そのため、2 つの URL スペースを処理するアプローチを改善する方法について、いくつかの提案をお待ちしております。REST API が Web アプリケーションの (利用可能な) 動作を決定し、Web アプリケーションにブックマーク可能な URL を保持するためのより良い方法はありますか? なぜなら今、私たちは完全に正しいとは思えないある種のハイブリッドなアプローチを持っているからです.

前もって感謝します。

よろしく、

リュック

4

1 に答える 1

2

それは難しい設定です。大まかに言うと、API にブックマークを追加する必要がありますが、RESTful システムはブックマークをやや思いとどまらせます。

考えられる解決策の 1 つは、正規の URL 構造を変更する可能性があるため、ブックマーク サービスは常にビットを変換できるため、前方互換性が保証されている、存在する現在のリソースのブックマーク (少し似ている) URL を返す「ブックマーク サービス」です。 .ly like url を canonical url に変換します。複雑に聞こえるかもしれませんが、私たちはこれを常に目にしており、SEO URL と呼んでいます。

1 つ目はリソースのような概要のリストであり、2 つ目は特定のリソースの取得である 2 つのリソースを表示する UI にそれをどのように一致させるかは、非常にトリッキーです。そのようなページには、表示されているものの状態が URL (おそらくフラグメント) に含まれていることを知っていると思います。そのようなコマンドを処理するのは[おそらく]コントローラであるため、入力として両方（リストリソースと拡張リソース）が必要になる可能性があります。URLは次のようになります。

list=http://path/to/list/results&expand=http://self/link/of/path

したがって、最後の部分は、それが今後も機能することを確認することです。繰り返しますが、これはブックマークの問題です。ブックマーク サービスを構築したくない場合に私が提案できることは、そのようなブックマークが必要な場合は、ユーザーを新しい URL に移行する必要があるということです。http://path/to/list/resultsに対してリクエストが行われ、それを切り替えたい場合は、それらを新しい正規 URL に 301 リダイレクトする必要があり、アプリはブックマークを更新する必要があります。このようなリダイレクトには &flag=deprecate_message パラメータを含めて、クライアントのブックマークが古く、置き換える必要があるという UI でのプレゼンテーションをトリガーできます。または、応答を内部的に転送し、非推奨フラグと正規 (または最新) リンクを古い URL への応答に含めることもできます。これにより、段階的な移行が発生します。

要約すると、HATEOAS が後方互換性と前方互換性を完全に解決できるとはまだ思えませんが、既存の手法よりもはるかに優れています。つまり、ユーザーを v2 に移行する方法について、API の v1 で決定を下す必要があります。

于 2015-05-18T20:25:50.233 に答える