asp.net-mvc - mvc - return created asp net core

Diferencia entre ApiController y Controller en ASP.NET MVC

Question

He estado jugando con ASP.NET MVC 4 beta y ahora veo dos tipos de controladores: ApiController y Controller .

Estoy un poco confundido en qué situaciones puedo elegir un controlador en particular.

Por ejemplo: si quiero devolver una vista, ¿tengo que usar ApiController o el Controller normal? Soy consciente de que la API web de WCF ahora está integrada con MVC.

Ya que ahora podemos usar ambos controladores, alguien puede indicar en qué situaciones ir para el controlador correspondiente.

Answer 1

¿Cuál preferirías escribir y mantener?

ASP.NET MVC

public class TweetsController : Controller {
  // GET: /Tweets/
  [HttpGet]
  public ActionResult Index() {
    return Json(Twitter.GetTweets(), JsonRequestBehavior.AllowGet);
  }
}

API Web ASP.NET

public class TweetsController : ApiController {
  // GET: /Api/Tweets/
  public List<Tweet> Get() {
    return Twitter.GetTweets();
  }
}

Answer 2

Cada método en la API web devolverá datos (JSON) sin serialización.

Sin embargo, para devolver los datos JSON en los controladores MVC, estableceremos el tipo de resultado de acción devuelto en JsonResult y llamaremos al método Json en nuestro objeto para asegurarnos de que esté empaquetado en JSON.

Answer 3

Es bastante sencillo decidir entre los dos: si está escribiendo una aplicación web / internet / intranet basada en HTML, tal vez con la ocasional llamada AJAX que devuelve json aquí y allá, quédese con MVC / Controller. Si desea proporcionar una interfaz basada en datos / REST-ful para un sistema, vaya con WebAPI. Puede combinar ambos, por supuesto, teniendo un ApiController para atender las llamadas AJAX desde una página MVC. Básicamente, el controlador se usa para mvc y api-controller se usa para Rest-API, puede usar ambos en el mismo programa que necesite

Answer 4

Me encanta el hecho de que el MVC6 de ASP.NET Core fusionó los dos patrones en uno porque a menudo necesito soportar ambos mundos. Si bien es cierto que puede ajustar cualquier Controller MVC estándar (y / o desarrollar sus propias clases de ActionResult ) para que se comporte y se comporte como un ApiController , puede ser muy difícil de mantener y probar: además, los métodos de Controllers regresan ActionResult mezclado con otros que devuelven datos en bruto / serializados / IHttpActionResult puede ser muy confuso desde la perspectiva del desarrollador, especialmente si no está trabajando solo y necesita llevar a otros desarrolladores a la velocidad con ese enfoque híbrido.

La mejor técnica que he llegado hasta ahora para minimizar ese problema en las aplicaciones web no Core de ASP.NET es importar (y configurar adecuadamente) el paquete de API web en la aplicación web basada en MVC, para poder tener lo mejor de ambos worlds: Controllers para vistas, ApiControllers para datos.

Para hacer eso, necesitas hacer lo siguiente:

• Instale los siguientes paquetes de API web usando NuGet: Microsoft.AspNet.WebApi.Core y Microsoft.AspNet.WebApi.WebHost .
• Agregue uno o más ApiControllers a su /Controllers/ carpeta.
• Agregue el siguiente archivo WebApiConfig.cs a su carpeta /App_Config/ :

using System.Web.Http;

public static class WebApiConfig
{
    public static void Register(HttpConfiguration config)
    {
        // Web API routes
        config.MapHttpAttributeRoutes();

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

Finalmente, deberá registrar la clase anterior en su clase de inicio (ya sea Startup.cs o Global.asax.cs , dependiendo de si está utilizando la plantilla de inicio OWIN o no).

Startup.cs

 public void Configuration(IAppBuilder app)
 {
    // Register Web API routing support before anything else
    GlobalConfiguration.Configure(WebApiConfig.Register);

    // The rest of your file goes there
    // ...
    AreaRegistration.RegisterAllAreas();
    FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
    RouteConfig.RegisterRoutes(RouteTable.Routes);
    BundleConfig.RegisterBundles(BundleTable.Bundles);

    ConfigureAuth(app);
    // ...
}

Global.asax.cs

protected void Application_Start()
{
    // Register Web API routing support before anything else
    GlobalConfiguration.Configure(WebApiConfig.Register);

    // The rest of your file goes there
    // ...
    AreaRegistration.RegisterAllAreas();
    FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
    RouteConfig.RegisterRoutes(RouteTable.Routes);
    BundleConfig.RegisterBundles(BundleTable.Bundles);
    // ...
}

Este enfoque, junto con sus ventajas y desventajas, se explica con más detalle en esta publicación que escribí en mi blog.

Answer 5

Usa el controlador para renderizar tus vistas normales. La acción de ApiController solo devuelve datos que se serializan y se envían al cliente.

aqui esta el link

Citar:

Nota Si ha trabajado con ASP.NET MVC, entonces ya está familiarizado con los controladores. Funcionan de manera similar en la API web, pero los controladores en la API web se derivan de la clase ApiController en lugar de la clase Controller. La primera gran diferencia que notará es que las acciones en los controladores de API web no devuelven vistas, sino que devuelven datos.

ApiControllers están especializados en la devolución de datos. Por ejemplo, se encargan de serializar de forma transparente los datos en el formato solicitado por el cliente. Además, siguen un esquema de enrutamiento diferente de manera predeterminada (como en: mapeo de URL a acciones), proporcionando una API REST-ful por convención.

Probablemente podría hacer cualquier cosa utilizando un Controlador en lugar de un ApiController con la codificación manual (?). Al final, ambos controladores se basan en la base ASP.NET. Pero tener una API REST-ful es un requisito tan común hoy en día que se creó WebAPI para simplificar la implementación de dicha API.

Es bastante sencillo decidir entre los dos: si está escribiendo una aplicación web / internet / intranet basada en HTML, tal vez con la ocasional llamada AJAX que devuelve json aquí y allá, quédese con MVC / Controller. Si desea proporcionar una interfaz basada en datos / REST-ful para un sistema, vaya con WebAPI. Puede combinar ambos, por supuesto, teniendo un ApiController para atender las llamadas AJAX desde una página MVC.

Para dar un ejemplo del mundo real: actualmente estoy trabajando con un sistema ERP que proporciona una API REST-ful a sus entidades. Para esta API, WebAPI sería un buen candidato. Al mismo tiempo, el sistema ERP proporciona una aplicación web altamente AJAX que puede utilizar para crear consultas para la API REST-ful. La aplicación web en sí misma podría implementarse como una aplicación MVC, haciendo uso de la WebAPI para obtener metadatos, etc.