Tenho lido alguns tutoriais sobre a implantação de Web Apps e API Apps no Azure. No entanto, ainda não tenho certeza de por que você usaria um em vez do outro.
Posso criar uma nova solução .NET com controladores de API e implantá-la como um aplicativo da Web, então por que exigiria especificamente um aplicativo de API? Eles são otimizados especificamente para ASP.NET Web API, onde os Web Apps são para entrega de HTML?
Respostas:
Atualizando a resposta para o estado atual do Azure,
Os serviços de aplicativos agora substituem todos os tipos de aplicativos móveis, Api e da Web como uma única estrutura de aplicativo com todas as funcionalidades acumuladas para tornar as coisas mais acessíveis entre os tipos de aplicativos. Atualmente, todos os aplicativos da Web, móveis e APIs são chamados coletivamente de serviços de aplicativos. Ainda oferecemos ao cliente a capacidade de criar um aplicativo móvel e um aplicativo da Web na galeria, mas isso basicamente se transforma em um aplicativo de serviço de aplicativo.
https://azure.microsoft.com/en-us/documentation/articles/app-service-api-apps-why-best-platform/
Recursos para dispositivos móveis funcionam para aplicativos da Web, bem como tabelas fáceis e API fácil. E recursos para aplicativos de API como API Cors e definições de API agora funcionam em aplicativos da web também. Um cliente pode hospedar um único aplicativo da web para atuar como qualquer serviço móvel ou uma API com todos os recursos oferecidos por meio dos serviços de aplicativo.
Também temos um novo serviço de visualização voltado especialmente para aplicativos de API, oferecendo uma experiência de gerenciamento para suas APIs. Basicamente, você pode controlar a geração de páginas de API de teste, reunir análises de execução, aceleração e muito mais. Confira o blog de recursos para saber mais sobre os recursos de gerenciamento de API do Azure. E sim, você pode hospedar as APIs como um aplicativo de serviço de aplicativo e conectar as coisas com o gerenciamento de API.
https://azure.microsoft.com/en-us/documentation/articles/api-management-get-started/
Houve um momento em que havia diferenças entre os diferentes tipos de serviço de aplicativo, mas isso não é mais verdade. A documentação agora afirma:
A única diferença entre os três tipos de aplicativo (API, web, móvel) é o nome e o ícone usados para eles no portal do Azure.
Portanto, não importa mais em qual tipo de serviço de aplicativo você escolhe implantar (a menos que você se importe com a aparência do ícone).
ATUALIZAR
Aplicativos de função agora são a exceção. A criação de um aplicativo de funções altera a interface do usuário no portal. O aplicativo da web subjacente, no entanto, não é diferente. Definir uma configuração de aplicativo chamada FUNCTIONS_EXTENSION_VERSION= ~1transforma qualquer aplicativo da web em um aplicativo de função (sem a interface do usuário no portal).
Existem muitas pequenas diferenças entre a API da Web e os aplicativos de API, mas as diferenças mais notáveis e importantes são
Implementação Swagger nativa - Quando você cria um aplicativo API no Visual Studio, a referência swagger vem por padrão. O Swagger fornece recursos muito amigáveis ao desenvolvedor para que os consumidores de API interajam com sua API por meio da IU Swagger. Além disso, a API baseada em Swagger fornece geração de SDK do cliente (cliente baseado em .Net e cliente baseado em Javascript), o que torna fácil chamar APIs da mesma forma que uma chamada de método regular. Observação: a implementação do Swagger na API da Web regular é possível manualmente.
Capacidade de publicar seus aplicativos de API no Azure Market Place. Azure Market Place é o repositório público para todos os aplicativos de API que podem ser consumidos gratuitamente ou por cobrança.
este vídeo de 15 minutos do Canal 9 oferece uma excelente visão geral sobre os aplicativos Api.
Para complementar a resposta de Greg, aqui está um artigo ainda mais recente que descreve as diferenças.
Resumindo:
"Os principais recursos dos aplicativos de API - autenticação, CORS e metadados de API - foram movidos diretamente para o serviço de aplicativos. Com essa mudança, os recursos estão disponíveis na Web, em aplicativos móveis e de API. Na verdade, todos os três compartilham o mesmo Microsoft.Web / tipo de recurso de sites no Gerenciador de recursos. "
E aqui está outra observação importante:
"Se sua API já estiver implantada como um aplicativo da Web ou aplicativo móvel, você não precisa reimplantar seu aplicativo para aproveitar os novos recursos."
Isso pode depender do que você está tentando fazer, mas você usaria uma API da Web ao criar um serviço. ASP.Net Web API é uma estrutura para construir serviços HTTP que podem ser consumidos por uma ampla gama de clientes. Isso permite que você o construa não apenas para um aplicativo da web, mas que ele seja aberto para se conectar a aplicativos Android, IOS, web, Windows 8, WPF, etc.
Portanto, se você precisa de um serviço da Web, mas não do SOAP, pode usar a API da Web.
Aqui meus comentários:
Aplicativo API: usado para funcionalidades específicas. Acionar essa funcionalidade a partir de um URL. Pode ser usado para usar com GET, POST, PUT, DELETE. Pode receber parâmetros em BODY (Json). Resposta com código de status válido (falha, sucesso.)
Web APP: Um aplicativo implantado com múltiplas funcionalidades, por exemplo um catálogo para criar, atualizar e excluir clientes ou para criar um ERP completo.
APP de função: é muito semelhante ao app de API, usado para funcionalidade específica. Acionar essa funcionalidade a partir de um URL. Pode ser usado para usar com GET, POST, PUT, DELETE. Pode receber parâmetros em BODY (Json). Resposta com código de status válido (falha, sucesso.)
Na verdade, você pode implantar seu aspnet webapi no Azure WebApp e um auto-host em Funções de Trabalho.
No WebApp (antigos sites do Azure), ele será implantado no IIS, para que você possa aproveitar as vantagens dos recursos do IIS.