As @Brian Mains recommends, in your situation, you should use an ApiController
because, as you say, it does not return a view. Controller
should be used for your UI.
The answer to your question about is ApiController
just for CRUD takes you dangerously close to the REST flame wars.
A pure REST approach to this would be to think of your restore database operation as creating a DatabaseRestoreRequest resource (and therefore should be a POST).
POST <Host>/Api/DatabaseRestoreRequest
Since the restore is probably a lengthy operation (especially for large databases), the body of the POST response would represent a resource with a unique identifier and a status that could be one of
- InProgress
- Failed
- Complete
Having done a POST to initiate the restore (status would be InProgress), you would then make a GET request, providing the unique identifier. The GET response would give the updated status. You could call GET repeatedly until the response had a status of Complete.
GET <Host>/Api/DatabaseRestoreRequest/<requestID>
You may also have a DELETE operation, which could cancel the restore operation.
DELETE <Host>/Api/DatabaseRestoreRequest/<requestID>
If this seems over complicated and unnatural to you, you could just use a pattern like that used by the Windows Azure management API (and others). This uses a URI scheme that indicates a resource in the main URI and then the operation as a query string parameter
For example, to re-image a virtual machine you would do a POST to
https://management.core.windows.net/<subscription-id>/services/hostedservices/<cloudservice-name>/deploymentslots/<deployment-slot>/roleinstances/<role-instance-name>?comp=reimage
In your case it could be something like
POST <Host>/Api/Database?comp=restore
POST is traditionally used for this kind of operation because they are often non-idempotent. Idempotent means that if you repeat it several times it has the same effect as if you do it just once). PUT is supposed to be idempotent. POST does not have to be. This comes from the W3C:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
REST purists might decide to flame and downvote me for suggesting the second option. But hey...