2

たとえば、アプリケーション用の HTTP API があり、それらのアプリケーションにはユーザーがいます。関係アプリケーション - ユーザーは 1:m です。モデルはアプリケーションで完全に分割されます。つまり、アプリケーションは自己完結型であり、ユーザー用のグローバル プールはありません。したがって、ユーザーを見つけるには、事前にアプリケーションを知る必要があります。

この場合に適切な REST API を設計するのは簡単ではありません。通常、URI はモデルの実装方法に依存すべきではありません。リソースに対処するだけです。また、URI もできるだけ短くする必要があります。

現在、ユーザーの URI がどのように見えるべきかについて考えています。基本的にはそのままでいいと思います

/user/{id}

外部から見れば、これは良いことです。しかし、データのパーティショニングを維持したいので、グローバル プールですべてのアプリケーション ユーザーを参照したり、利用可能なすべてのアプリケーションでユーザーを検索したりしたくありません。つまり、アプリケーションに関するコンテキストを追加する必要があります。URI を次のようにする

/application/{id}/user/{id}

問題を解決します。私のモデルを念頭に置いている間、それは理にかなっています。アプリケーションとユーザーは複合的なものです。つまり、ユーザーはアプリケーションの外では意味を持ちません。一方、ユーザーはスタンドアロンのリソースになる可能性があると考えています。そして、私のIDはUUIDであるため、URLは非常に長くなり、見栄えがよくありません(これが引数としてカウントされる場合:))

3 番目のオプションは、HTTP 要求に追加のヘッダーを配置することです。それは次のようになります

X-Foo-Application: {id}
GET /user/{id}

これが私が現時点で行っている方法です。ID が UUID であるため、(UUID の設計により) URI が異なるリソースに対して 2 回存在する可能性はありません。しかし、それがスタンドアロンのリソースとパーティション化されたデータの間で妥協する適切な方法であるかどうかはまだわかりません。

あるいは、明らかな問題解決アプローチ #4 を見逃しているだけかもしれません。どんなヒントでも大歓迎です

4

1 に答える 1

1

ユーザーの ID はグローバルに一意であるため、両方を見つけました。

/user/{id}

と

/application/{id}/user/{id}

許容できる。2 番目のパスは、ユーザーとアプリケーションの関係をより明確にします。しかし、ユーザー ID がグローバルに一意であるという性質に基づいて、おそらく最初のパスを選択するでしょう。

あなたが書く：

そして、私のIDはUUIDであるため、URLは非常に長くなり、見栄えがよくありません(これが引数としてカウントされる場合:))

ではない正確に ：）

あなたの3番目のアプローチはあまり好きではありません。X-Foo-Application: {id}サーバーは追加のヘッダーをどのように使用しますか? ユーザーを識別する必要はなく、URI の一部ではありません。

于 2012-11-07T11:13:16.777 に答える