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

回答

相关问题