使用和组织dto的REST架构

本文关键字：REST 架构 dto | 更新日期: 2023-09-27 18:09:37

对于开发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的最佳方法是什么?

使用和组织dto的REST架构

我想我要问自己的问题是:我是想优化我的API的网络带宽和耦合它到HTTP方法，还是我想公开我的API作为一个简单的模型，以允许消费者(当前和未来)更大的自由度，他们如何实现他们使用的API?

我几乎总是根据需要开发DTO。使用。net匿名类型和/或像AutoMapper这样的映射工具很容易做到这一点。DTO与UI是高度耦合的，在不知道UI是什么样子的情况下，你很难通过预先设计它们来优化你的开发。例外是Delete，其中您只需要ID。

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

相关文章：