17

マルチテナント環境でHTTPリクエストのテナントを識別する次の2つの方法を検討しています-URIにテナントをハードコーディングします：

/{tenantUuid}/foos/{id}

または、次のようなカスタムHTTPヘッダーでテナントを渡します。

X-Auth-Token: 7d2f63fd-4dcc-4752-8e9b-1d08f989cc00"

（類似：http ：//docs.openstack.org/api/quick-start/content/ ）

{id}はすべてのテナントで一意であることに注意してください。したがって、リソース/{tenantUuid}/foos/{id}は引き続き一意に識別されます。foo

私の質問は-これにカスタムヘッダーを使用することは理論的に正しいのか、それともカスタムヘッダーの使用は落ち着かないのかということです。ヘッダーが非推奨になったことも承知しX-...ていますが、問題はその事実を無視していることです。

ありがとう。

4

3 に答える 3

8

URIはリソースを一意に識別する必要があります。

しかし、これは承認とアクセスと直交しています。2人が同じリソースを要求する可能性があります。何も得られない、コピーが省略される、またはエラーが発生する。一方、もう一方は、Authorizationヘッダーで適切に識別されるため、すべてを取得します。

これで、URIに一意のURIの一部としてテナントIDを含めることができますが、これに問題はありません。ただし、いずれの場合も、リソース自体は（URIのコンポーネントまたは内部状態を含めて）どのテナントに属しているかを「認識」します。

したがって、あなたの場合、HTTP Authorizationヘッダーを使用してリクエスターを適切に識別し、その情報を使用して、特定のリクエストに対する応答が内部的に決定されるかどうかを判断する必要があります。リクエスターは、システム上のテナントをまったく、1つ、一部、またはすべて表示することを許可されている場合があります。

このユースケースでは、カスタムヘッダーはまったく必要ありません。

于 2012-10-25T23:47:15.680 に答える
1

リソースを識別するためにテナントIDが必要な場合、RESTfulな方法はそれをURLに含めることです。そうでない場合（idはテナント間で一意です）、技術的には、URLまたはヘッダーにそれは必要ありません。

idはすべてのテナントで一意であるため、/ foos / {id}はそのリソースを一意に識別でき、RESTfulです。

リソースをアドレス指定する方法としてカスタムヘッダーを使用することは避けます。代わりに、受け入れタイプ、認証トークンなどの補助情報を渡すために使用する必要があります。リソースを識別してURLに入れることが重要かどうかを判断する必要があります。

于 2012-10-25T23:24:32.773 に答える
0

アプリがユーザーを異なるテナントから分離することは、クレイグのリストのようなアプリが都市から分離することよりも興味深いかもしれません。

しかし、URIにすべての種類の区切りを表示しますか？次のようなURIが必要です/comcast/blackeyes/long-haired/london/か？

RESTfulまたはRESTenoughであっても、この質問には答えられません。それはただの味の問題です。

于 2015-06-29T17:15:38.063 に答える