2014-02-08 45 views
4

當(持久性)模型類與暴露的REST資源表示不同時,在大多數情況下使用任何REST框架(球衣,resteasy,spring-mvc) 即使大部分時間,傳入的json表示(例如,創建和更新)都不同,那麼傳出的json表示(例如list,get,..)。尋找關於不同REST資源表示的命名約定的建議

我在尋找一些很好的命名約定來解決這個問題。

實施例結構:

+-- my.comp.domain.Customer 
+-- my.comp.rest.resource.CustomerResource (or CustomerController) 

的CustomerResource將在內部使用客戶堅持和檢索數據。 但是對於外部(Request + Response對象),它將使用一點點不同的結構。

我現在所做的是:

+-- my.comp.rest.representation.CustomerRequest 
+-- my.comp.rest.representation.SimpleCustomerResponse 
+-- my.comp.rest.representation.SimpleCustomerCollectionResponse 
+-- my.comp.rest.representation.ExtendedCustomerResponse 

那些基本上只包含簡單的字段POJO。使用的REST框架將使用這些將它轉換爲json。

其他人使用不同的namings?我很樂意提供建議。

回答

0

而不是有請求,響應作爲單獨的嘗試使用常見的基本表示來代表最多和基於需求添加額外的。

POST /客戶/ - 類可以是 'CustomerRepresentation/CustomerContract/CustomerRp/representation.CustomerModel'

GET /客戶/ {ID} - 返回相同CustomerRepresentation或上述

PUT - 相同以及

GET /客戶/ - CustomerListRepresentation或相同

鏈接可以連接到其相應的對象,作爲創建可選的東西。

請讓我知道您的想法。

+0

無論何時當您不通過客戶ID佔位符時返回列表,那麼您的網址應描述列表即GET/customers –

+0

否則GET/customer/{id} –

+0

更新所有情況下的URL複數。不需要基於單數/複數來區分它們,只需定義所有複數就可以使api變得簡單就足夠了。每個人都可以自己選擇,而不是混淆太多的慣例。 – DarkKnight