構建RESTful服務代碼的正確方法

我是使用Jersey編寫RESTful服務的新手。以下是示例代碼。構建RESTful服務代碼的正確方法

我創建了一個類「用戶」這個類裏面&把一切。

// 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 
} 


}

有誰可以請告訴我更好的方法來構建我的服務。我沒有什麼想法，但不確定這些想法是否真的很好，還是保持現在的實施。

問題

服務類（用戶）的具體落實。這是一個好主意，創建一個接口（比如IUser）並執行User類的實現？
我應該創建一個控制器類&注入IUser作爲控制器中的依賴關係嗎？ Jersey是否提供任何開箱功能來創建控制器類。

阿圖爾

來源

2017-03-02 Atul Sureka

我經常做的就是春節和澤西結合起來。澤西島處理所有請求/響應和表示（通過工廠和/或生成器）相關的東西。 Spring @Service處理所有業務邏輯，持久性等。

因此，資源接受（或不）請求，將其委託給服務（將結果作爲模型返回給資源）將此模型轉換爲匹配（Json或XML或類似內容）表示形式，並將其作爲響應返回。

我在這裏看到的好處是，資源中的通信（和身份驗證），@Service中的業務邏輯，與模型對象的組件間通信以及通過表示對象與客戶端通信。

來源

2017-03-18 13:06:31 sschrass

這也可能有所幫助：https：//www.toptal.com/spring/top-10-most-common-spring-framework-mistakes – sschrass

有很多指導方針，在那裏，將相互矛盾的細節，但基本上遵循類似的模式，當涉及到設計你的REST結構。

就我個人而言，我在您的實例中使用以下內容：/v1/users如果請求用戶擁有權限，他們可能會看到系統中所有用戶的數組。

我避免把句子寫成REST路徑。相反，讓登錄的用戶的當前我將創建沿着

/v1/users/me

線的東西這將相當於

/v1/users/123（123是我的user_id）

這裏有一個像樣的文章教程涵蓋基礎知識。

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

來源

2017-03-02 20:48:55 geeves

構建RESTful服務代碼的正確方法

回答

相關問題