RESTfulサービスコードを構造化する正しい方法

Question

私はJerseyを使用してRESTfulサービスを書く初心者です。以下はサンプルコードです。

クラス「User」&を作成しました。クラス内にすべてを配置しました。

// Service to get the user information 

@Path("/User") 
public class User { 

@GET 
    @Produces(MediaType.APPLICATION_JSON) 
    @Consumes(MediaType.APPLICATION_JSON) 
    @Path("/getloggedinuser") 
    public String getUserInfo(@Context HttpServletRequest httpServletRequest) { 

        // Some code to get the user information 
    // Call M1 
    M1(); 
} 

private void M1(){ 
// Some other business logic 

// Call another method 
M2(); 
} 

private void M2(){ 
// Some other business logic 
} 


} 

誰でも私のサービスを構成するためのより良い方法を教えてください。私はアイデアはほとんどありませんが、それが実際には良いかどうか、あるいは現在の実装を維持するかどうかはわかりません。

質問

1. サービスクラス（ユーザー）具体的な実装を持っています。インターフェイス（IUser）を作成し、Userクラスの実装を行うのは良い考えですか？

2. コントローラークラスを作成しますか？&コントローラーにIUserを依存関係として挿入しますか？ Jerseyは、ボックスクラスの機能を提供してコントローラクラスを作成します。

アトゥール

Answer 1

は春とジャージーを組み合わせることです。 Jerseyはすべての要求/応答と表現（工場やビルダーを介して）に関連するものを処理します。 Spring @Serviceは、すべてのビジネスロジック、永続性などを処理します。

したがって、リソースは要求を受け入れ（またはしない）、サービスに委譲し（リソースにモデルとして結果を返します）、リソースこのモデルをマッチング（JsonまたはXML、または同様のもの）表現に変換し、レスポンスとして返します。

私が見る利点は、リソース内の明確なコミュニケーション（および認証）、@Service内のビジネスロジック、モデルオブジェクトとのコンポーネント間通信、および表現オブジェクトを介したクライアントとの通信です。

Answer 2

細部に互いに矛盾が、それはあなたのRESTの構造を設計することになると、主に同様のパターンをたどるだろうそこに多くのガイドラインがあります。

私はあなたのインスタンスで次のものを使用します：/v1/users要求しているユーザーに権限がある場合は、システムのすべてのユーザーの配列が表示されます。

文章をRESTパスとして書くことを避けます。代わりに、私は

/v1/users/123にこれは同等だろう

/v1/users/me

の線に沿って何かを作成することになり現在ログインしているユーザーを取得するために

ここでまともなチュートリアルの記事があります（123は私のuser_idです）基本をカバーしています。私は、多くの場合、何

https://blog.qmo.io/ultimate-guide-to-api-design/