Spring POST json實體

我會盡量簡化它，因爲我找不到有關此問題的教程，我認爲它屬於設計REST API的最佳實踐。Spring POST json實體

我有兩個實體 - 角色（ID，姓名） - 用戶（ID，姓名，角色等）

當進行POST請求某些控制器是什麼做的最好的方法，以json的方式。

{ 
"id": 1, 
"name": "Luis", 
"rol":{ 
"id": 1, 
"name":Administrator, 
"users" : [ 
//I think this is for the bidirectional relationship so 
can I avoid this property as well?? 
] 
}, 
"another" : bla bla bla 
}

對於這種方法，我必須把所有相關實體的屬性？這意味着我必須創建一個具有此結構的JSON，或者可以省略屬性，這裏有個問題擺脫了我的頭腦Spring如何知道這是一個實體，因此它可以創建一個Role對象並因此與User建立關係？

還是我必須張貼這樣的：

{ 
    "id": 1, 
    "name": "Luis", 
    "role_id" : 1, 
    "another" : bla bla bla 
    }

所以，當這個控制器knwos，首先它會發現通過使用角色，可以說Role.findById（）當然我使用的服務圖層...然後將其附加到用戶。

這是最好的方法是什麼？

謝謝。

來源

2017-01-13 Luisinho Rojas

在我看來，這個問題特別有趣，因爲它回顧了一個非常常見的開發者的陷阱，即理解設計和實現之間的界限。首先，讓我們指出一個非常重要的概念：您的API與您的業務對象分離。您的API可以由一個對Java或Spring一無所知的架構師來設計，並且關心更少的User或Role類。

在REST中，服務器和客戶端交換資源表示，這意味着服務器可以自由確定該資源的最有意義的表示形式。換句話說，無論您使用的是JSON，XML還是其他類型，您都不會因爲它以某種形式出現在您的後備對象中而被迫在您的API中包含某些信息。

API中暴露的資源存在於另一個維度中。對於Spring控制器，他們是不可知論的。

所以，回答你的問題是：發送有意義該操作的信息。服務器知道其餘的。

我不得不承認，你的第二個問題「Spring如何知道這是一個實體，所以它可以創建一個Role對象，從而與用戶建立關係？」聽起來有點不可思議。 Spring Controllers將HTTP請求綁定到類方法。這些方法是像下面

@RequestMapping(value = "/users", method = RequestMethod.POST) 
public String createUser(@RequestBody UserModel user) { 
    //... 
}

所以，當你火POST到正確的URL的請求將從分派，以你DispatcherServlet最後到你Controller和createUser方法。有效載荷（即JSON表示）現在被解組爲根據用戶表示（例如，包括id,name和roleId）定義的UserModel類。此時，您可以控制一切，因爲您可以使用user執行所有您需要的操作。可能您會創建一個Role對象和一個User對象，完成這兩個類之間的依賴關係，調用您的DAO或任何其他對象，等待持久層完成其操作並將HTTP狀態返回給客戶端（使用location標頭填充，如果你想成爲RESTful）。

來源

2017-01-13 22:19:48 MaVVamaldo

很好的解釋...關於春天是怎麼知道的問題......我的意思是路過的時候裏面的用戶角色對象，有這樣： ' 「角色」：{ 「ID」：1 } ' 或這樣 ' 「角色」：{ 「名」：「管理員」 } ' 甚至 ' 「ROL」：{ 「ID」：1，「名」：管理員，「用戶」：[ ] } ' 它是否獲取所有屬性，然後映射它們以知道哪個角色在說？我的意思是，它是否獲取ById，ByName，ByAnyOtherProperty？ –

當時你在你的控制器中，它執行你在那裏寫的代碼。所以*你*而不是Spring會使用你喜歡的策略獲取某些東西。請記住，在這一點saveUser正在執行。可能你會在你的UserModel實例中尋找確定角色的屬性。如果它是一個ID，您將通過id執行一次抓取。如果您決定使用不同的表示形式，則會使用另一個獲取策略。 – MaVVamaldo

Spring POST json實體

回答

相關問題