複数のAPIの類似のエンドポイント

Question

マイクロサービスとして設定されているAPIがいくつかあります。一つのAPIは、ユーザー（ユーザーAPI）を管理することであり、次のようになります。

/users     GET, POST 
    /{id}    GET, PUT, DELETE 

そして、そこのセキュリティ情報（アクセスの役割、権限など）を管理するために使用されている別のAPIであり、ユーザーに作成user APIには、セキュリティAPIで定義されているgroupを割り当てることができます。その関連付けをセキュリティマイクロサービスまたはユーザーマイクロサービスで行うべきか？

私の最初の考えは、すべてのアプリケーションがセキュリティ情報を要求するセキュリティマイクロサービスです。その、およびuserは一つだけgroupに割り当てることができると、私はその後のエンドポイントを思い付く：

/users/{id}/group  GET, POST, DELETE 

しかし、それはユーザーのマイクロサービスでより多くの属するようにそのエンドポイントは感じています。オプションある他のエンドポイントは以下のとおりです。

/groups/{id}/users  GET, POST, DELETE 
       /{id} GET, DELETE 

しかし、その後、userが複数のグループに割り当てることができることを思われてしまうということ。しかし、userがgroupに関連付けられている場合、以前に関連付けられていたgroupとの関連付けが解除されるように設計することができます。

私は知らないこれらのタイプのAPIコールを処理する最良の方法はありますか？

Answer 1

「正しい」方法がないと思います。ここで私はそれにどのようにアプローチするかです。基づいて

：

ユーザーが グループに関連付けられている場合、それが以前に関連付けられて たグループからの関連付けを解除するようにしかし、私はそれを設計することができます。

/groups/{id}/users  GET, POST, DELETE 
       /{id} GET, DELETE 

Idが変化するであろうと、あなたはので、あなたが別のグループへのユーザーの切り替え後に呼び出すURLを変更しなければならないという点で、このエンドポイントはいくつかの問題を引き起こします。したがって、連続したコールは新しいエンドポイントに移動する必要があります。

たとえば、/groups/1/users/1は有効ですが、ユーザーがグループを移動すると、/groups/1/users/1は結果を返さなくなります。ユーザーがグループを切り替えた場合、エンドポイントがそれクリーナーと明確に私の意見では保持され、変更されません

/users/{id}/group  GET, POST, DELETE 

：それは今/groups/2/users/1

とのに対しなります。ユーザーはまだ同じであり、グループは、このユーザーに関連付けられていることは明らかだが、それは常に私が推測することid

にuserために関連したgroupを返しますと呼ばれているものgroup問題ではありません。一番下の行は、ユーザーのグループを取得している場合、エンドポイントは、あなたが達成しようとしているものを反映すべきであるということです。

/groups/{id}/users  GET, POST, DELETE 

：

/users/{id}/group  GET, POST, DELETE 

か、グループのすべてのユーザーを取得している場合