JPA實體我有，我可以送JPA實體休息的請求和/或獲取JPA實體休息響應我應該使用在休息的請求和/或響應
@RequestMapping(value = "/products", method = RequestMethod.POST)
public @ResponseBody ProductDetailsResponse createNewProduct(@RequestBody ProductDetails newProduct)
throws Exception {
ProductDetails的情況是一個實體
@Entity
@Table(name = "product")
public class ProductDetails {
我應該利用這一點，還是有一些從實體某種轉變到另一種對象
雖然沒有硬性規定，但它不被認爲是一種很好的做法（由於很好的理由&其非常有見解的觀點）使用JPA實體作爲DTO（數據傳輸對象）。
除了在尺寸方面是實體的輕量級版本，DTO還有其他優點。
我認識到的一個這樣的優點是關係也更輕，對於一對多的單向關係，您的子實體也會引用您的父實體，但是您可以在DTO中打破該鏈，這樣可以避免大量JSON轉換和無限循環相關問題。
我發現在DTO級別上做對象轉換（反之亦然）的JSON比在實體級別更容易，因爲實體表示DB圖表而非客戶端業務圖表。
一個簡單的通用工具類來完成轉換（從DTO到實體，反之亦然）就足夠了。您可以使用here所述的模型映射器API。
我不讓實體跨越服務層邊界，它的所有DTO都在控制器上，我在控制器上進行轉換。
有關於這個主題，你可以瀏覽所以很有趣的問題，
Should I convert an entity to a DTO inside a Repository object and return it to the service layer?
Conversion of DTO to entity and vice-versa
其他鍋爐板代碼是DTO方法的一個缺點。
從技術上看，它是精細響應使用實體。實體只能被序列化爲響應輸出格式（JSON或XML）。
編寫測試將會創建完整的實體對象（所有字段設置爲非null）並嘗試對其進行序列化是一個好主意。即使單個不可序列化的字段也會導致異常。你寧願在測試期間發現，而不是在發佈之後。
在簡單情況下（CRUD應用程序），其中實體的每個字段都是需要響應的，這是很好的選擇。
如果你不需要實體的每個字段作爲迴應，你可以使用@JsonView。
如果您的回答與實體（新字段，轉換）顯着不同，創建單獨的DTO對象以進行回覆更好。這樣，您將能夠分別演進Web API（DTO）和數據庫模式（實體）。