REST架构使用和组织DTO

Question

开发REST Web服务有5个基本用例（我认为）

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

DTO提供与Web服务交互所需数据的最佳表示。

我喜欢这两个概念，但我正在努力的是如何组织DTO与他们如何与特定的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网络服务相关的最佳方式是什么？

Answer 1

我想我会问自己的问题是：我是否希望优化我的API以获得网络带宽并将其与HTTP方法结合使用，或者我是否希望将我的API作为简单模型公开以允许消费者（当前和未来）他们如何实现API使用的更大自由度？

Answer 2

我几乎总是根据需要开发DTO。使用.NET匿名类型和/或映射实用程序（如AutoMapper）可以轻松完成。 DTO与UI高度耦合，您几乎无法通过预先设计它们来优化您的开发，而无需确切知道您的UI将会是什么样子。例外是删除，您将需要该ID。