我开始想知道我是不是在这里遇到反模式,所以请告知最佳实践.
我正在设计一个带有一组各种端点的REST API,我想将请求和响应参数包装到漂亮的DTO中.
例如,一些端点:
public async Task<JobStateResponse> GetJobState(JobStateRequest request);
public async Task<JobDownloadRespose> DownloadJob(JobDownloadRequest request);
public async Task<CreateJobResponse> CreateJob(CreateJobRequest request);
Run Code Online (Sandbox Code Playgroud)
问题是这些请求和响应是相对类似的DTO,例如:
public class JobStateResponse{
public int TaskId {get;set;}
public string ExternalId {get;set;}
public State State {get;set;}
}
public class JobDownloadResponse {
public int TaskId {get;set;}
public string ExternalId {get;set;}
public string JobContent {get;set;}
}
Run Code Online (Sandbox Code Playgroud)
我想为这些和继承创建一个基类,但在某些情况下,某些属性可能是多余的...这意味着这些方法没有明确指出它们工作所需的参数.
我的意思是,使用DTO参数公开API端点,该参数具有7个属性,但实际上只需要2个声音非常糟糕 ......
另一方面,为大多数端点维护单独的DTO似乎也是一种过度杀伤,也是维护地狱.
而且我想要的最后一件事是请求的几个基类的复杂关系,因为这可能是一个更糟糕的主要问题.
那么,请求<>响应处理的正确方法是什么?
编辑:关于'基于意见'的标志 - 我正在寻找处理这个问题的最佳做法.我知道它可以通过多种方式完成,但我想避免使用地雷/反模式.另外,我要说到目前为止我对这些答案非常满意.