Reputation: 34297
I have a Web API project that currently has a ServicesController. I get the list of services, for a server, by making this call:
$http.get(rootWebApiUrl + '/api/services/' + server)
The ServicesController has this signature:
public IEnumerable<FirstSolarService> Get(string id)
Now I want to make two more calls.
I have a choice to make as far as my Web API controllers go. Do I put this all in the ServicesController, or should I create separate controllers for each type of object I'm returning? If the latter, then I would create these two controllers:
But what's awkward about that (maybe) is that I'd call each of those by passing in something other than the ID of the folder or file. To get folders, I'd pass in the service name. To get files, I'd pass in the path of the service. Is that the way it is supposed to be done? I'd just like to do this the correct way.
Upvotes: 1
Views: 94
Reputation: 107508
I don't think you should split it up into multiple controllers, unless they each are going to each have considerable functionality, or if Folders and Files are real domain objects/repository entities.
As you may know, you are not limited to the Get
/Post
/Put
/Delete
convention for method names in WebAPIs. You can specify the action name if you want. For example, if you wanted a Folders
method, you could add one:
[HttpGet]
public ReturnType Folders(string serviceName)
{
}
Your API URL for the above would be '/api/services/folders/' + server
.
You don't need to create a custom route -- the default one incorporates an {action}
component. Philosophically, I would ask yourself: are services composed of folders? Can folders exists without services? If folders depend on services, then I think it's ok to include that functionality in the services controller. If they don't, then split up the controllers based on functionality.
Upvotes: 2