Как спроектировать операции без CRUD в веб-API MVC4?

Я начинаю новый проект, используя ASP.NET MVC4 и Visual Studio 2012. С точки зрения дизайна API, большинство примеров сосредоточены на основных операциях CRUD с помощью команд PUT, GET, POST и DELETE над сущностями (как и следовало ожидать). Я читал следующее:

http://www.asp.net/web-api/overview/web-api-routing-and-actions/routing-in-aspnet-web-api

В статье предполагается, что если я выберу карту маршрута как

routes.MapHttpRoute(
    name: "DefaultApi",
    routeTemplate: "api/{controller}/{id}/{action}",
    defaults: new { action = RouteParameter.Optional }
);

Это скорее подход в стиле RPC; из чего я сделал вывод, что они рекомендуют два маршрута с двумя контроллерами для разделения каждой операции:

Возможно, что-то вроде родительского объекта CRUD:

routes.MapHttpRoute(
    name: "Parent",
    routeTemplate: "api/{controller}/{id}/{action}",
    defaults: new { id = RouteParameter.Optional }
);

и для дочерней сущности CRUD:

routes.MapHttpRoute(
    name: "Child",
    routeTemplate: "api/user/{id}/{controller}",
    defaults: new { id = RouteParameter.Optional }
);

С точки зрения данных/грубости это имеет смысл. Однако что делать, если вы хотите выполнить несложную операцию над сущностью (например, /User/NoahBawdy/SignIn или /User/NoahBawdy/ChangePassword)? Я мог видеть, что это действие PUT или POST, но действительно ли для этого требуется собственный контроллер? Является ли это неправильным подходом к разработке API для таких операций?

Любое понимание высоко ценится, как всегда.


rest c# asp.net-web-api
person Chris Baxter    schedule 10.07.2012    source источник

Ответы (1)


arrow_upward
3
arrow_downward

Вы подняли несколько интересных моментов в своем посте. Я столкнулся с аналогичной проблемой в проекте, над которым я работаю, и мой подход заключается в добавлении параметра действия в конфигурацию маршрутизации.

С этим изменением я мог добавить любой метод к контроллеру и вызывать его из клиента. Это позволяет избежать необходимости указывать несколько контроллеров для методов, которые концептуально принадлежат одному и тому же контроллеру.

Омар

person Bah    schedule 10.07.2012
comment
Спасибо за вклад; примерно тоже так думаю. Мне любопытно посмотреть, будет ли кто-нибудь еще высказываться по этому вопросу (т. Е. Является ли он концептуально неправильным/правильным); хотя движение, кажется, довольно легкое по этому вопросу. - person Chris Baxter; 10.07.2012
comment
В конечном итоге я пошел по этому пути, я думаю, что справедливо иметь сочетание RESTful ApiControllers, где это уместно, и использовать ApiControllers, ориентированные на действия, где это оправдано. - person Chris Baxter; 22.07.2012