REST架構DTO的

爲了開發一個REST Web服務有5個基本用例（在我看來）REST架構DTO的

/api/entities  - GET 
/api/entities/{id} - GET 
/api/entities  - POST 
/api/entities/{id} - PUT 
/api/entities/{id} - DELETE

一個DTO提供所需數據的最佳表徵與Web服務交互。

我喜歡這兩個概念，但我在哪裏掙扎是如何組織DTO的關於他們如何與特定的Web服務交互。

每個Web服務應該只有一個DTO嗎？例如：

EntityDto 
    - Property1 
    - Property2 
    - Property3 
    - Property4 
    - Property5

或者應該有每個用例的DTO？例如：

GetEntityDto 
    - Property1 
    - Property2 
    - Property3 
    - Property4 
    - Property5 

AddEntityDto 
    - Property2 
    - Property3 
    - Property4 
    - Property5 

EditEntityDto 
    - Property4 
    - Property5

我看到它的方式，如果只能更新2個屬性，爲什麼要發送所有5個？

處理DTO與REST Web服務有關的最佳方法是什麼？

來源

2013-04-16 David

我給了你一個話題，但是別忘了還有其他的方法，比如'PATCH'，它是用於部分修改的。 – thecoshman

我想我會問自己的問題是：我想優化我的API的網絡帶寬，並將其耦合到HTTP方法，或者我想公開我的API作爲一個簡單的模型，以允許消費者（目前和未來）在他們如何實現他們對API的使用方面擁有更大的自由度？

來源

2013-04-16 12:57:59

我幾乎總是根據需要開發DTO。使用.NET匿名類型和/或像AutoMapper這樣的映射工具很容易完成。 DTO與UI高度耦合，你幾乎無法通過預先設計來優化開發，而不必知道你的UI會是什麼樣子。例外情況是您將需要該ID的刪除。

來源

2013-04-16 16:06:39 Aidin

回答

相關問題