构建 Rest API 请求/响应模型的最佳实践 [关闭]

Question

我需要有关构建 RESTful API 项目的请求-响应模型的最佳方法的建议。

我有所有 API 响应的基类：

public class BaseResponse
{
    public string Id { get; set; }
    public string Name { get; set; }
}

如果我有以下方法只返回客户Id和Name，并且，暂时，没有其他字段需要返回客户...

[HttpGet]
[Route("Customer")]
public Task<IActionResult> GetCustomers()
{
    var result = _customerManager.GetCustomers(ModelState);
    return ReturnResponse(result, ModelState);
}

...那么我的问题是：对于GetCustomers 方法和Manager 类，以下哪个实现更好？

1 - 使用BaseResponse 直接返回我的数据：

public List<BaseResponse> GetCustomers(ModelStateDictionary modelState)
{
    return new List<BaseResponse>().Add(
        new BaseResponse { id = "1", Name = "Mike" },
        new BaseResponse { id = "2", Name = "Tom" }
    );
}

或者

2 - 为CustomerResponseModel 创建一个新类，如下所示，并使用它返回我的数据（一开始保持为空）以考虑到 我还不知道的新字段 将来可能会添加。

public class CustomerResponseModel : BaseResponse
{

}

public List<CustomerResponseModel> GetCustomers(ModelStateDictionary modelState)
{  
    return new List<CustomerResponseModel>().Add(
        new CustomerResponseModel { id = "1", Name = "Mike" },
        new CustomerResponseModel { id = "2", Name = "Tom" }
    );
}

我知道这两种方法都没有内存或性能缺陷，但我需要知道这种情况下的最佳做法是什么。

第二种方法只有一个已知的缺点：如果我将它应用于用于同一案例的所有项目实体，它会影响服务器端的项目大小，并且很常见，因为会有太多空类在我的项目中，它只继承自BaseResponse。

我需要您从设计和结构的角度为我的项目提供最佳方法的建议，并想知道它是否存在任何其他缺点。

Answer 1

在这种情况下，我认为始终遵循 YAGNI（“你不需要它”）和 KISS（“保持简单，小”）原则。因此，如果您不知道将来是否有必要，请不要这样做。它降低了程序的复杂性并提高了可维护性。

可维护性，因为当我使用您的类并看到返回类型是“BaseResponse”时，我知道响应是一个简单的数据传输对象，始终具有相同的字段。所以我不必去探索每个继承的类。