Utilisation de WebAPI ou de MVC pour renvoyer JSON dans ASP.NET
Je construis une application ASP.NET MVC qui est lourde en scripts client. Elle utilisera JSON et jQuery pour manipuler le DOM.
Je crois comprendre que Web API Controller et MVC Controller peut renvoyer JSON.
Étant donné mon scénario, devrais-je utiliser un Web API Controller ou un MVC Controller ?
Les contrôleurs API Web peuvent être créés et hébergés dans n’importe quelle application ASP.NET, pas seulement les applications MVC. Par conséquent, une raison évidente de créer une API Web réside dans le fait que vous n’avez pas de serveur frontal MVC (par exemple, des services Web classiques, RESTful hébergés par votre société/organisation).
Les contrôleurs MVC reposent généralement sur le framework MVC. Si vous examinez les modèles par défaut et la plupart des travaux effectués par la communauté et vos pairs, vous remarquerez que presque tous les contrôleurs MVC sont implémentés avec la vue en tête.
Personnellement, j'utilise les contrôleurs MVC lorsque je souhaite répondre avec un View () et j'utilise une API Web pour tout ce qui ne dépend pas d'un affichage particulier.
Bien sûr, il y a des réserves, mais généralement si vous n'avez pas besoin du comportement Model Binding de MVC, si votre service est centré sur les données et que les opérations sont centrées sur les données (opérations CRUD, par exemple), vous souhaiterez probablement un 'contrôleur API Web 'au lieu d'un' Model-View Controller '. À l'inverse, si vos opérations sont centrées sur View (par exemple, fournir une page d'administrateur à 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 souhaiterez plutôt un contrôleur MVC.
Personnellement, j'utilise des contrôleurs 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 est destiné à la création d'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, il vous suffit de parler au client en JSON.
Même si votre site Web est principalement axé sur les scripts client, vous utiliseriez toujours ASP.NET MVC Controller, n'est-ce pas? Et puisque vous avez peut-être déjà logiquement divisé vos contrôleurs en fonction d'entités, il est donc logique d'ajouter ces méthodes de traitement Json plutôt que de créer une autre classe spécifiquement pour les API Web.
Donc, pour votre situation particulière (si je comprends bien), je resterais avec les contrôleurs.
La réponse se résume à la séparation des préoccupations, accélère la création de services et repose sur la convention plutôt que sur la configuration.
La principale responsabilité des contrôleurs est de travailler en tant que coordinateur entre la vue et votre modèle, tandis que la principale responsabilité de l'API est de travailler sur des données. Dans le cas des conventions d'API, il est très facile d'effectuer des opérations CRUD. Voici le mappage entre l'opération CRUD et les actions HTTP
- GET: Lire
- POST: Créer
- PUT: Mise à jour
- DELETE: Supprimer
Ainsi, avec les API, il n'est pas nécessaire de créer des actions séparées et de les attribuer avec des actions HTTP.
Dans ce scénario, je recommanderais WebApi car il est idéal pour transférer des données telles que celle-ci sur la base de requêtes Javascript. Je vais généralement développer mes contrôleurs WebApi afin qu'ils renvoient un objet convivial JSON qui peut ensuite être analysé facilement par mon code Javascript.
Le seul temps réel où vous voudriez utiliser une action sur un contrôleur MVC pour ce genre de choses serait si vous vouliez générer du HTML et remplacer les segments de votre page par des appels Javascript.
Par exemple:
Vous avez un Datepicker 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 code HTML nécessaire à l'aide de Javascript, mais il est généralement déconseillé de créer beaucoup de code HTML à l'aide de Javascript. Il serait bien préférable que C # construise le code HTML, puis le renvoie via une vue partielle, de cette manière, vous risqueriez moins de rencontrer des erreurs lors de l’analyse Javascript. Sans oublier que cela rend le HTML beaucoup plus facile à écrire.
Le seul souci que j'ai avec ApiController est qu'il est basé sur un site et non sur une zone . Un site ne peut avoir qu'un seul sous-dossier apicontroller pour que vous nommiez vos méthodes de contrôleur . Il existe des situations dans lesquelles vous voudrez peut-être dupliquer un contrôleur nom dans différents domaines:
domaine.com/api/area1/controller1/
domaine.com/api/area2/controller1/
Je me souviens qu'il existe certains 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 (réponse la plus élevée), mais je ne sais pas pourquoi, car je suis un peu confus et que j'essaie encore de comprendre la prémonition suivante (probablement incorrecte) -
- Utilisez WebAPI Controller pour transmettre des données JSON au client afin que celui-ci puisse gérer la manipulation de la vue. Ce processus NE requiert PAS une vue, mais plutôt une simple réponse à ce que l’on appelle la méthode (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 le chargement de la page (c'est-à-dire pas pour les applications SPA).
Vous voyez, je ne sais tout simplement pas si je me trompe et que je suis confus parce que la dernière ligne de la réponse de Shaun indique "J'utilise des contrôleurs MVC pour gérer le routage de base du navigateur et la livraison du SPA." - Je ne sais peut-être pas ce qu'est un client reposant quand j'ai supposé que ce pourrait être une méthode JavaScript qui reçoit une réponse au format JSON. Il s'agit du message le plus proche dans Stackoverflow qui a été associé à distance comme réponse à ma question. Je réponds donc à ce message au lieu de dupliquer éventuellement des questions.