Différence entre ApiController et Controller dans ASP.NET MVC

J’ai joué avec ASP.NET MVC 4 beta et je vois maintenant deux types de contrôleurs: ApiController et Controller .

Je suis un peu confus dans quelles situations je peux choisir un contrôleur particulier.

Par exemple: Si je veux retourner une vue, je dois utiliser ApiController ou le Controller ordinaire? Je suis conscient que l’API Web WCF est maintenant intégrée à MVC.

Étant donné que nous pouvons maintenant utiliser les deux contrôleurs, quelqu’un peut-il indiquer à quelles situations s’adresser pour le contrôleur correspondant.

Utilisez Controller pour afficher vos vues normales. L’action ApiController ne renvoie que les données sérialisées et envoyées au client.

Voici le lien

Citation:

Remarque Si vous avez travaillé avec ASP.NET MVC, vous connaissez déjà les contrôleurs. Ils fonctionnent de manière similaire dans l’API Web, mais les contrôleurs de l’API Web dérivent de la classe ApiController au lieu de la classe Controller. La première différence majeure que vous remarquerez est que les actions sur les contrôleurs d’API Web ne renvoient pas de vues, elles renvoient des données.

Les ApiControllers sont spécialisés dans le retour des données. Par exemple, ils veillent à sérialiser de manière transparente les données dans le format demandé par le client. De plus, ils suivent un schéma de routage différent par défaut (comme dans: mapper les URL vers les actions), fournissant une API REST-ful par convention.

Vous pourriez probablement faire quelque chose en utilisant un Controller au lieu d’un ApiController avec le codage manuel (?). Au final, les deux contrôleurs s’appuient sur la base ASP.NET. Mais posséder une API REST-ful est une exigence si courante aujourd’hui que WebAPI a été créé pour simplifier l’implémentation d’une telle API.

C’est assez simple de décider entre les deux: si vous écrivez une application Web / Internet / Intranet basée sur HTML – peut-être avec un appel AJAX occasionnel renvoyant json ici et là – restz avec MVC / Controller. Si vous souhaitez fournir une interface pilotée par les données / REST-ful à un système, utilisez WebAPI. Bien sûr, vous pouvez combiner les deux en ayant un ApiController capable de répondre aux appels AJAX depuis une page MVC.

Pour donner un exemple concret: je travaille actuellement avec un système ERP qui fournit une API REST-ful à ses entités. Pour cette API, WebAPI serait un bon candidat. Parallèlement, le système ERP fournit une application Web hautement adaptée à AJAX que vous pouvez utiliser pour créer des requêtes pour l’API REST-ful. L’application Web elle-même pourrait être implémentée en tant qu’application MVC, en utilisant WebAPI pour extraire des métadonnées, etc.

Que préférez-vous écrire et maintenir?

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 Get() { return Twitter.GetTweets(); } }

J’adore le fait que MVC6 d’ASP.NET Core a fusionné les deux modèles en un seul parce que je dois souvent supporter les deux mondes. Bien qu’il soit vrai que vous pouvez modifier n’importe quel Controller MVC standard (et / ou développer vos propres classes ActionResult ) pour agir et se comporter comme un ApiController , il peut être très difficile de maintenir et de tester: ActionResult mélangé à d’autres données IHttpActionResult données raw / serialized / IHttpActionResult peut être très déroutant du sharepoint vue du développeur, surtout si vous ne travaillez pas seul et devez amener d’autres développeurs à accélérer cette approche hybride.

La meilleure technique que j’ai utilisée jusqu’à présent pour minimiser ce problème dans les applications Web ASP.NET non-core consiste à importer (et configurer correctement) le package d’API Web dans l’application Web basée sur MVC, afin que je puisse obtenir le meilleur des deux. mondes: Controllers pour les vues, ApiControllers pour les données.

Pour ce faire, vous devez procéder comme suit:

Installez les packages d’API Web suivants à l’aide de NuGet: Microsoft.AspNet.WebApi.Core et Microsoft.AspNet.WebApi.WebHost .
Ajoutez un ou plusieurs ApiControllers à votre dossier /Controllers/ .
Ajoutez le fichier WebApiConfig.cs suivant à votre dossier /App_Config/ :

 using System.Web.Http; public static class WebApiConfig { public static void Register(HttpConfiguration config) { // Web API routes config.MapHttpAtsortingbuteRoutes(); config.Routes.MapHttpRoute( name: "DefaultApi", routeTemplate: "api/{controller}/{id}", defaults: new { id = RouteParameter.Optional } ); } }

Enfin, vous devez enregistrer la classe ci-dessus dans votre classe de démarrage ( Startup.cs ou Global.asax.cs , selon que vous utilisez ou non le modèle de démarrage OWIN).

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); // ... }

Cette approche – avec ses avantages et ses inconvénients – est expliquée plus en détail dans le post suivant .

Chaque méthode de l’API Web renverra des données (JSON) sans sérialisation.

Toutefois, pour renvoyer les données JSON dans les contrôleurs MVC, nous définirons le type de résultat de l’action renvoyé sur JsonResult et appelons la méthode Json sur notre object pour nous assurer qu’il est empaqueté dans JSON.