MVC3 REST Routes & Http Verbs - PullRequest
       17

MVC3 REST Routes & Http Verbs

10 голосов
/ 04 января 2012

В результате моего предыдущего вопроса я обнаружил два способа обработки REST-маршрутов в MVC3.

Это дополнительный вопрос, в котором я пытаюсь понять фактические различия / тонкости между этими двумя подходами. Я ищу авторитетный ответ, если это возможно.

Метод 1: одиночный маршрут, с именем действия + атрибуты глагола Http для действий контроллера

  1. Зарегистрировать отдельный маршрут в Global.asax, используя указанный параметр action.

    public override void RegisterArea(AreaRegistrationContext context)
    {
        // actions should handle: GET, POST, PUT, DELETE
        context.MapRoute("Api-SinglePost", "api/posts/{id}", 
            new { controller = "Posts", action = "SinglePost" });
    }
    
  2. Применение атрибутов ActionName и HttpVerb к действиям контроллера

    [HttpGet]
    [ActionName("SinglePost")]
    public JsonResult Get(string id)
    {
        return Json(_service.Get(id));
    }
    [HttpDelete]
    [ActionName("SinglePost")]
    public JsonResult Delete(string id)
    {
        return Json(_service.Delete(id));
    }
    [HttpPost]
    [ActionName("SinglePost")]
    public JsonResult Create(Post post)
    {
        return Json(_service.Save(post));
    }
    [HttpPut]
    [ActionName("SinglePost")]
    public JsonResult Update(Post post)
    {
        return Json(_service.Update(post););
    }
    

Метод 2: уникальные маршруты + ограничения глагола с атрибутом глагола Http для действий контроллера

  1. Регистрация уникальных маршрутов в Global.asax с помощью HttpMethodContraint

    var postsUrl = "api/posts";
    
    routes.MapRoute("posts-get", postsUrl + "/{id}", 
        new { controller = "Posts", action = "Get",
        new { httpMethod = new HttpMethodConstraint("GET") });
    
    routes.MapRoute("posts-create", postsUrl, 
        new { controller = "Posts", action = "Create",
        new { httpMethod = new HttpMethodConstraint("POST") });
    
    routes.MapRoute("posts-update", postsUrl, 
        new { controller = "Posts", action = "Update",
        new { httpMethod = new HttpMethodConstraint("PUT") });
    
    routes.MapRoute("posts-delete", postsUrl + "/{id}", 
        new { controller = "Posts", action = "Delete",
        new { httpMethod = new HttpMethodConstraint("DELETE") });
    
  2. Использовать только атрибут глагола Http в действиях контроллера

    [HttpGet]
    public JsonResult Get(string id)
    {
        return Json(_service.Get(id));
    }
    [HttpDelete]
    public JsonResult Delete(string id)
    {
        return Json(_service.Delete(id));
    }
    [HttpPost]
    public JsonResult Create(Post post)
    {
        return Json(_service.Save(post));
    }
    [HttpPut]
    public JsonResult Update(Post post)
    {
        return Json(_service.Update(post););
    }
    

Оба эти метода позволяют мне иметь уникальные методы Controller Action Methods и позволяют использовать маршруты RESTful, связанные с глаголами ... но чем принципиально отличается ограничение маршрута от использования имени действия прокси?

Ответы [ 3 ]

1 голос
/ 03 июня 2012

Вы не получите достоверного ответа, вот мои 2 цента:

Я предпочитаю метод 2, потому что тогда у вас есть все ваши маршруты в одном месте. Вы можете инкапсулировать свою маршрутизацию в метод, например MapResourceRoutes(string controller, string uri) и используйте его несколько раз в вашем API.

Также метод 2 дает вам четко названные маршруты, которые вы можете использовать для связывания и обратной маршрутизации.

0 голосов
/ 29 января 2013

На данный момент правильный ответ - использовать веб-API.

0 голосов
/ 23 января 2012

Я не знаю, что вы когда-нибудь найдете авторитетный ответ, но я предложу свое мнение, и, как вы можете судить по моим соображениям, мое мнение имеет значение ;-).Мой пурист считает, что первый вариант более чистый, однако мой опыт показывает, что вспомогательные методы, такие как Url.Action (), иногда могут испытывать проблемы с определением правильного маршрута с помощью этого подхода, и я выбрал второй метод, поскольку он действительно имеет толькопоследствия внутри, как API выглядит идентично потребителю.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...