Web API -控制器设计

Web API - Controller Design

本文关键字:控制器 API Web      更新时间:2023-09-26

我有一个Web API项目,目前有一个ServicesController。我通过以下调用获取服务器的服务列表:

$http.get(rootWebApiUrl + '/api/services/' + server)

ServicesController有这样的签名:

public IEnumerable<FirstSolarService> Get(string id)

现在我想再打两个电话。

  1. 获取服务本身路径内的Windows文件夹
  2. 用户在#1中选择文件夹后,显示该文件夹中的dll。

我有一个选择,只要我的Web API控制器去。我应该把这些都放在ServicesController中,还是应该为我返回的每种类型的对象创建单独的控制器?如果是后者,那么我会创建这两个控制器:

  1. FoldersController
  2. FilesController

但尴尬的是(也许)我通过传入文件夹或文件的ID以外的其他东西来调用它们。要获取文件夹,我将传入服务名称。为了获取文件,我将传入服务的路径。这是应该做的吗?

我不认为你应该把它分成多个控制器,除非它们每个都有相当大的功能,或者如果文件夹和文件是真正的域对象/存储库实体。

你可能知道,你并不局限于Get/Post/Put/Delete约定在webapi中的方法名。如果需要,可以指定操作名称。例如,如果您想要一个Folders方法,您可以添加一个:

[HttpGet] 
public ReturnType Folders(string serviceName)
{
}

上面的API URL将是'/api/services/folders/' + server

你不需要创建自定义路由——默认的路由包含一个{action}组件。理论上,我会问你自己:服务是由文件夹组成的吗?没有服务的文件夹可以存在吗?如果文件夹依赖于服务,那么我认为在服务控制器中包含该功能是可以的。如果没有,那么就根据功能拆分控制器。