スプリングブートRESTパスマッピング

Question

私は、休憩サービスのためのPATHマッピングを作成するためのベストプラクティスを考えています。 のは、我々は次のパスを持っているとしましょう：

/users POST 
/users/1 PATCH, GET 
/users/1/contacts GET, POST 
/users/1/contacts/1 GET, PATCH 

質問です - コントローラを作成するためのベストプラクティスは何か。 たとえば、私たちは技術的にこれらのマッピングをすべて入れることができるUserControllerを持っています。または、別のコントローラを作成する必要があります（UserController、 ContactsController）。私たちがすべてを下に置くならば、下のUserControllerは です。

@RequestMapping("users") 
@RestController 
public class UserController { 

    @RequestMapping(method = RequestMethod.POST) 
    public ResponseEntity<Void> createUser() {} 

    @RequestMapping(method = RequestMethod.GET) 
    public User getUser() {} 

    @RequestMapping(value = "{id}/contacts", method = RequestMethod.GET) 
    public List<Contact> getContacts() {} 

    @RequestMapping(value = "{id}/contacts", method = RequestMethod.POST) 
    public ResponseEntity<Void> createContact() {} 

    ..... 
} 

個別のコントローラを作成する場合、パスをどのように整理する必要がありますか？ おそらくそれは愚かな質問ですが、誰かが経験を共有できるなら、私はうれしいでしょう。

Answer 1

今後、ユーザーに関連するエンティティの数が増加することを示唆しています。実体に応じて、それを分割することをお勧めされるように、それは明らかに： - > UserServiceの - > UserRepository、

ContactController - > ContactService - > ContactRepository、

FriendshipController -

UserControllerで>フレンドシップサービス - >友情レポジトリ

私の経験から、ユーザコントローラ

ユーザスコープの友情コントローラに関連

@RestController 
@RequestMapping("/user") 
public class UserController extends AbstractController { 

... 

    @RequestMapping(method = RequestMethod.POST) 
    public ResponseEntity<?> createUser(@RequestHeader("X-Auth-Token") Optional<String> @RequestBody User user) { 

... 

    @RequestMapping(method = RequestMethod.GET) 
    public ResponseEntity<?> listUsers(@RequestHeader("X-Auth-Token") Optional<String> authToken) { 
... 

：それは公理である

@RestController 
@RequestMapping("/user/{id}") 
public class FriendshipController extends AbstractController { 

... 

@RequestMapping(value = "/friendship/code", method = RequestMethod.POST) 
    public ResponseEntity<?> generateCodeForUser(@PathVariable("id") long id) { 

... 

@RequestMapping(value = "/friendship/code", method = RequestMethod.GET) 
    public ResponseEntity<?> retrieveCodeForUser(@PathVariable("id") long id) { 

... 

わからないが、私は私のコードを整理。

Answer 2

UsersとContactsの間のカップリングを除去するための別のコントローラのファンです（後でContactsを別のコンテキストで使用する場合はどうなりますか？ （すなわち、彼らが属するUserの独立した）

それらが分離されている場合、パスはあなたが持っているものと非常によく似ています：

ユーザー

/users GET, POST 
/users/{user-id} PATCH, GET 

コンタクト

/contacts GET, POST 
/contacts/{contact-id} GET, PATCH 

との間に依存関係がある場合とUsers（と1があるように、この場合には、それが見えます）、あなたはこのようにそれを持つことができます。

/contacts/for-user/{user-id} GET, POST 
/contacts/for-user/{user-id}/{contact-id} GET, PATCH 

これは、あなたが他のコンテキストに他のもの（だけではなく、ユーザー）、ユーザーに連絡先を追加することができます（関係なく、自分の連絡先の）

例えば、コーヒーメーカーのユーザー

/coffee-maker/users GET 

やコーヒーメーカーが失敗した場合、我々は修理のために連絡すればよいですか？

/coffee-maker/contacts GET 

はおそらくコーヒーメーカーの修理のための連絡先もユーザーである（しかし、彼らはする必要はありません）

が

もう一つは、あなたがそれを好転との接触がためであると言うことができますアプライアンス（つまり、コーヒーメーカー）

/contact/for-appliance/{appliance-id} GET 

私のポイントあなたはユーザーから連絡先を切り離す場合は、あなたが他のエンティティに連絡先を割り当てることができるということではなく、User -> Contactsように関係を強制する - 場合を除き、もちろん、あなたドンビジネスルールのためにそれらを切り離したい何後で場合 - どのような場合には、何らかの理由

は、彼らが（例えば）のユーザーと接点間の結合を削除すると、私は別々のコントローラのためのファンですマッピング