Diferencia entre ApiController y Controller en ASP.NET MVC

Solución:

Utilice Controller para representar sus vistas normales. La acción ApiController solo devuelve datos serializados y enviados al cliente.

aqui esta el link

Cita:

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, devuelven datos.

Los ApiControllers están especializados en devolver 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 forma predeterminada (como en: asignación de URL a acciones), lo que proporciona una API REST por convención.

Probablemente podría hacer cualquier cosa usando 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 WebAPI se creó para simplificar la implementación de dicha API.

Es bastante simple decidir entre los dos: si está escribiendo una aplicación web / Internet / intranet basada en HTML, tal vez con la llamada AJAX ocasional que devuelve json aquí y allá, quédese con MVC / Controller. Si desea proporcionar una interfaz basada en datos / REST a un sistema, vaya con WebAPI. Puede combinar ambos, por supuesto, con un ApiController que atienda 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 compatible con AJAX que puede utilizar para crear consultas para la API REST-ful. La aplicación web en sí podría implementarse como una aplicación MVC, haciendo uso de WebAPI para obtener metadatos, etc.

¿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();
  }
}

Me encanta el hecho de que MVC6 de ASP.NET Core fusionó los dos patrones en uno porque a menudo necesito admitir ambos mundos. Si bien es cierto que puede modificar cualquier MVC estándar Controller (y / o desarrollar el tuyo propio ActionResult clases) para actuar y comportarse como un ApiController, puede ser muy difícil de mantener y probar: además de eso, tener Controladores métodos que regresan ActionResult mezclado con otros que regresan sin procesar / serializados /IHttpActionResult Los datos pueden ser muy confusos desde la perspectiva del desarrollador, especialmente si no está trabajando solo y necesita que otros desarrolladores se pongan al día con ese enfoque híbrido.

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

Para hacer eso, debe hacer lo siguiente:

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

---

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 Puesta en marcha clase (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 pros y contras, se explica con más detalle en esta publicación que escribí en mi blog.

---

---

Utiliza Nuestro Buscador