J'ai lu quelques didacticiels sur le déploiement d'applications Web et d'applications API sur Azure. Cependant, je ne sais toujours pas pourquoi vous utiliseriez l'un sur l'autre.
Je peux créer une nouvelle solution .NET avec des contrôleurs API et la déployer en tant qu'application Web, alors pourquoi aurais-je spécifiquement besoin d'une application API? Sont-ils optimisés spécifiquement pour l'API Web ASP.NET, où en sont les applications Web pour la diffusion de HTML?
Réponses:
Mettre à jour la réponse à l'état actuel d'Azure,
App Services remplace désormais toutes les saveurs Mobile, Api et Web Apps en tant que framework d'application unique avec toutes les fonctionnalités transférées pour rendre les choses plus accessibles dans tous les types d'applications. Actuellement, toutes les applications Web, mobiles et Api sont appelées collectivement App Services. Nous proposons toujours au client de pouvoir créer une application mobile et une application Web dans la galerie, mais cela se résume essentiellement à une application App Service.
https://azure.microsoft.com/en-us/documentation/articles/app-service-api-apps-why-best-platform/
Fonctionnalités pour le travail mobile pour Web App ainsi que Easy Tables et Easy API. Et les fonctionnalités des applications API telles que API Cors et les définitions d'API fonctionnent désormais également sur les applications Web. Un client peut héberger une seule application Web pour agir comme n'importe quel service mobile ou une API avec toutes les fonctionnalités offertes par les services de l'application.
Nous avons également un nouveau service en avant-première ciblant particulièrement les applications API en offrant une expérience de gestion pour vos API.En gros, vous pouvez contrôler la génération de pages API d'essai, collecter des analyses d'exécution, des accélérations et bien plus encore. Consultez le blog des fonctionnalités pour en savoir plus sur les fonctionnalités de gestion des API Azure. Et oui, vous pouvez héberger les API en tant qu'application App Service et relier les choses à la gestion des API.
https://azure.microsoft.com/en-us/documentation/articles/api-management-get-started/
Il y avait un moment où il y avait des différences entre les différents types de services d'application, mais ce n'est plus vrai. La documentation indique maintenant:
La seule différence entre les trois types d'applications (API, Web, mobile) est le nom et l'icône qui leur sont utilisés dans le portail Azure.
Le type de service d'application sur lequel vous choisissez de déployer n'a donc plus d'importance (sauf si vous vous souciez de l'apparence de l'icône).
METTRE À JOUR
Les applications de fonction sont désormais l'exception. La création d'une application de fonction modifie l'interface utilisateur dans le portail. Cependant, l'application Web sous-jacente n'est pas différente. La définition d'un paramètre d'application nommé FUNCTIONS_EXTENSION_VERSION= ~1transforme toute application Web en une application de fonction (moins l'interface utilisateur dans le portail).
Il existe de nombreuses différences mineures entre les API Web et les applications API, mais les différences très notables et clés sont
Implémentation native de Swagger - Lorsque vous créez une application API dans Visual Studio, la référence Swagger est fournie par défaut. Swagger fournit des fonctionnalités très conviviales aux développeurs pour que les consommateurs d'API interagissent avec votre API via l'interface utilisateur de Swagger. De plus, les API basées sur Swagger fournissent la génération de SDK client (à la fois client basé sur .Net et client basé sur Javascript) qui facilite l'appel d'API, tout comme l'appel de méthode ordinaire. Remarque: la mise en œuvre de Swagger sur l'API Web standard est possible manuellement.
Possibilité de publier vos applications API dans Azure Market Place. Azure Market Place est le référentiel public de toutes les applications API pouvant être consommées gratuitement ou moyennant des frais.
cette vidéo de 15 minutes de Channel 9 donne un excellent aperçu des applications Api.
Pour compléter la réponse de Greg, voici un article encore plus récent décrivant les différences.
Pour résumer:
"Les principales fonctionnalités des applications API - authentification, CORS et métadonnées API - ont été transférées directement dans App Service. Avec ce changement, les fonctionnalités sont disponibles dans les applications Web, mobiles et API. En fait, les trois partagent le même Microsoft.Web / type de ressource sites dans Resource Manager. "
Et voici une autre note importante:
"Si votre API est déjà déployée en tant qu'application Web ou application mobile, vous n'avez pas à redéployer votre application pour profiter des nouvelles fonctionnalités."
Cela peut dépendre de ce que vous essayez de faire, mais vous utiliseriez une API Web lorsque vous créez un service. L'API Web ASP.Net est un cadre permettant de créer des services HTTP pouvant être utilisés par un large éventail de clients. Cela vous permet de le créer non seulement pour une application Web, mais aussi de l'ouvrir pour vous connecter aux applications Android, aux applications IOS, aux applications Web, aux applications Windows 8, aux applications WPF, etc.
Donc, si vous avez besoin d'un service Web mais que vous n'avez pas besoin de SOAP, vous pouvez utiliser l'API Web.
Voici mes commentaires:
Application API: utilisée pour des fonctionnalités spécifiques. Déclencher cette fonctionnalité à partir d'une URL. Peut être utilisé avec GET, POST, PUT, DELETE. Peut recevoir des paramètres chez BODY (Json). Réponse avec un code d'état valide (échec, succès.)
Web APP: Une application déployée avec de multiples fonctionnalités, par exemple un catalogue pour créer, mettre à jour et supprimer des clients ou pour créer un ERP complet.
Fonction APP: est très similaire à l'application API, utilisée pour une fonctionnalité spécifique. Déclencher cette fonctionnalité à partir d'une URL. Peut être utilisé avec GET, POST, PUT, DELETE. Peut recevoir des paramètres chez BODY (Json). Réponse avec un code d'état valide (échec, succès.)
En fait, vous pouvez déployer votre webapi aspnet sur Azure WebApp et un auto-hôte sur les rôles de travail.
Sur WebApp (anciens sites Web Azure), il sera déployé sur IIS, afin que vous puissiez profiter des fonctionnalités IIS.