Utilisation de WebAPI ou MVC pour renvoyer JSON dans ASP.NET

Je construis une application ASP.NET MVC qui est lourde de script client, elle utilisera JSON et jQuery pour manipuler le DOM.

Ma compréhension est que Web API Controller et MVC Controller peuvent renvoyer JSON.

Compte tenu de mon scénario, dois-je utiliser un contrôleur API Web ou un contrôleur MVC ?

Les contrôleurs API Web peuvent être créés et hébergés dans n'importe quelle application ASP.NET, pas seulement dans les applications MVC. Ainsi, une raison évidente de créer une API Web est si vous ne disposez pas d'un frontal MVC (par exemple, des services Web classiques RESTful hébergés par votre entreprise / organisation).

Les contrôleurs MVC s'appuient généralement sur MVC Framework, si vous regardez les modèles par défaut et la plupart du travail effectué par la communauté et vos pairs, vous remarquerez que presque tous les contrôleurs MVC sont implémentés avec la vue à l'esprit.

Personnellement, j'utilise des contrôleurs MVC lorsque j'ai l'intention de répondre avec une vue (), et j'utiliserai une API Web pour tout ce qui ne dépend pas d'une vue particulière.

Il y a des mises en garde, bien sûr, mais de manière générale, si vous n'avez pas besoin du comportement de liaison de modèle de MVC, votre service est centré sur les données et les opérations sont centrées sur les données (par exemple, les opérations CRUD), vous voudrez probablement un contrôleur d'API Web 'au lieu d'un' Model-View Controller '. Inversement, si vos opérations sont centrées sur la vue (par exemple, fournir une page d'administration utilisateur à l'utilisateur), ou si vous avez besoin de la liaison de modèle de MVC pour générer des `` partiels ajax '' (très peu probable), vous voudrez plutôt un contrôleur MVC.

Personnellement, j'utilise des contrôleurs d'API Web pour piloter des clients RESTful basés sur JSON, j'utilise des contrôleurs MVC pour gérer le routage de base du navigateur et la livraison du SPA.

WebAPI sert à créer une API. Si vous voulez que quelqu'un puisse utiliser votre API en XML, JSON, etc. Vous pouvez créer une API Web.

Dans votre cas, vous n'avez besoin de parler au client qu'en JSON.

Même si votre site Web est principalement piloté par un script client, vous utiliseriez toujours ASP.NET MVC Controller, n'est-ce pas? Et comme vous avez peut-être déjà divisé logiquement vos contrôleurs en fonction d'entités, il est logique d'ajouter ces méthodes de service json au lieu de créer une autre classe spécifiquement pour les API Web.

Donc, pour votre situation particulière (si je comprends bien), je m'en tiendrai aux contrôleurs.

La réponse se résume à la séparation des préoccupations, à accélérer la création de services et à s'appuyer sur la convention plutôt que sur la configuration.

La responsabilité principale des contrôleurs est de travailler en tant que coordinateur entre la vue et votre modèle, mais la responsabilité principale de l'API est de travailler sur les données. Dans le cas des conventions de l'API, il est très facile d'effectuer des opérations CRUD. Voici le mappage entre l'opération CRUD et les actions HTTP

• OBTENIR: Lire
• POST: Créer
• PUT: mise à jour
• SUPPRIMER: Supprimer

Ainsi, avec les API, vous n'avez pas besoin de créer des actions séparées et de les attribuer avec des actions HTTP.

Le seul problème que j'ai avec ApiController est qu'il est basé sur le site et non sur la zone. Un site ne peut avoir qu'un seul sous-dossier apicontroller pour que vous puissiez nommer vos méthodes de contrôleur. Dans certaines situations, vous souhaiterez peut-être dupliquer le nom du contrôleur dans différentes zones:

domain.com/api/area1/controller1/

domain.com/api/area2/controller1/

Je me souviens qu'il existe des paramètres de code personnalisés pour pouvoir le faire, mais cela ne fonctionne pas par défaut.

Je suis d'accord avec la réponse de Shaun Wilson (première réponse) mais je ne sais pas pourquoi car je suis juste un peu confus et j'essaie toujours de comprendre la prémonition suivante (probablement incorrecte) -

• Utilisez WebAPI Controller pour fournir des données JSON au client afin que le client puisse gérer la manipulation de vue. Ce processus ne nécessite PAS de vue mais plutôt simplement une réponse à ce que l'on appelle la méthode (c'est-à-dire une requête javascript) afin que le client puisse gérer toute manipulation côté client.
• Utilisez le contrôleur MVC lorsque vous devez utiliser les données pour manipuler une vue pendant ou juste après page_load (c'est-à-dire pas pour les applications SPA).

Vous voyez, je ne sais tout simplement pas comment je me trompe ici et je suis confus parce que la dernière ligne de la réponse de Shaun déclare "J'utilise des contrôleurs MVC pour gérer le routage de base du navigateur et la livraison du SPA." - peut-être que je ne sais pas tout à fait ce qu'est un client reposant quand j'ai supposé qu'il pouvait s'agir d'une méthode JavaScript qui recevait une réponse sous forme JSON. il s'agit du message le plus proche de Stackoverflow qui était lié à distance en tant que réponse à ma question, je réponds donc à ce message au lieu de dupliquer éventuellement des questions.

Dans ce scénario, je recommanderais WebApi car il est parfait pour transférer des données comme celle-ci en fonction de requêtes Javascript. Je développerai généralement mes contrôleurs WebApi afin qu'ils renvoient un objet convivial JSON qui peut ensuite être analysé facilement par mon Javascript.

Le seul temps réel où vous voudriez utiliser une action sur un contrôleur MVC pour ce genre de chose serait si vous vouliez générer du HTML et remplacer des segments de votre page par des appels Javascript.

Par exemple:

Vous disposez d'un sélecteur de date de l'interface utilisateur JQuery qui, lors de la sélection, génère une liste de boutons radio qui représentent les événements du jour choisi.

Dans ce scénario, vous pouvez utiliser WebApi pour renvoyer du JSON, puis générer le HTML nécessaire en utilisant Javascript, mais il est généralement déconseillé de créer beaucoup de HTML en utilisant Javascript. Il serait préférable que C # compile le HTML et le renvoie ensuite via une vue partielle, car de cette façon, vous risquez moins de rencontrer des erreurs avec l'analyse Javascript. Sans oublier que cela rend le HTML beaucoup plus facile à écrire.