使用和组织DTO的REST架构

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服务的交互。

每个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个属性呢？

处理与REST web服务相关的DTO的最佳方法是什么？

Answer 1

我想我会问自己的问题是:我是想为网络带宽优化我的API并将其耦合到HTTP方法，还是想将我的API公开为一个简单的模型，以便让消费者(当前和未来)在如何实现他们的API使用方面有更大的自由度？

Answer 2

我几乎总是根据需要开发DTO。使用.NET匿名类型和/或映射实用程序(如AutoMapper )可以轻松完成此任务。DTO与UI高度耦合，在不确切知道UI将是什么样子的情况下，您几乎无法通过预先设计它们来优化开发。例外情况是Delete，其中您只需要ID。

Answer 3

您是对的，您可以创建为视图定制的Dto，例如，查询仅在列表中显示的实体列表只能具有名称、id和图像，但详细页面可能需要具有来自同一实体的更多属性的Dto。DTO取决于您的端点和谓词。在一对多或多对多关系的情况下，POST可能要求您发送甚至不在实体中的数据，如类别id。通常，在多对多关系的情况下，您会在返回数据时省略链接，以避免递归/循环引用。