Я прочитал несколько руководств по развертыванию веб-приложений и приложений API в Azure. Однако я все еще не уверен, почему вы бы использовали одно вместо другого.
Я могу создать новое решение .NET с контроллерами API и развернуть его как веб-приложение, так зачем мне конкретно приложение API? Оптимизированы ли они специально для веб-API ASP.NET, тогда как веб-приложения предназначены для доставки HTML?
Ответы:
Обновление ответа на текущее состояние Azure,
Службы приложений теперь заменяют все разновидности мобильных приложений, Api и веб-приложений в виде единой платформы приложений со всеми функциями, переданными, чтобы сделать вещи более доступными для разных типов приложений. В настоящее время все веб-приложения, мобильные приложения и приложения Api вместе называются службами приложений. Мы по-прежнему предлагаем клиенту иметь возможность создавать мобильное приложение и веб-приложение в галерее, но в основном это разрешается в приложении-службе приложений.
https://azure.microsoft.com/en-us/documentation/articles/app-service-api-apps-why-best-platform/
Функции для мобильной работы с веб-приложением, такие как Easy Tables и Easy API. А функции для приложений API, такие как API Cors и определения API, теперь работают и в веб-приложениях. Клиент может разместить отдельное веб-приложение, которое будет действовать как любая мобильная служба или API со всеми функциями, предлагаемыми через службы приложений.
У нас также есть новая услуга в предварительном просмотре, особенно нацеленная на приложения API, предлагая возможности управления для ваших API. В основном вы можете управлять созданием страниц API try, собирать аналитику выполнения, регулировать и многое другое. Посетите блог о функциях, чтобы узнать больше о функциях управления API Azure. И да, вы можете разместить API в качестве приложения службы приложений и подключиться к API Management.
https://azure.microsoft.com/en-us/documentation/articles/api-management-get-started/
Был момент, когда существовали различия между разными типами сервисов приложений, но это уже не так. В документации теперь говорится:
Единственная разница между тремя типами приложений (API, веб, мобильные) - это имя и значок, используемые для них на портале Azure.
Таким образом, больше не имеет значения, какой тип службы приложений вы выберете для развертывания (если вас не волнует, как выглядит значок).
ОБНОВИТЬ
Приложения-функции теперь являются исключением. Создание приложения-функции изменяет пользовательский интерфейс на портале. Однако базовое веб-приложение ничем не отличается. Установка параметра приложения с именем FUNCTIONS_EXTENSION_VERSION= ~1превращает любое веб-приложение в приложение-функцию (за исключением пользовательского интерфейса на портале).
Между веб-API и API-приложениями существует множество незначительных различий, но наиболее заметными и ключевыми различиями являются
Собственная реализация Swagger. Когда вы создаете приложение API в Visual Studio, ссылка на Swagger предоставляется по умолчанию. Swagger предоставляет пользователям API очень удобные для разработчиков функции для взаимодействия с вашим API через пользовательский интерфейс Swagger. Кроме того, API на основе Swagger обеспечивает генерацию клиентского SDK (как клиента на основе .Net, так и клиента на основе Javascript), что упрощает вызов API, как обычный вызов метода. Примечание. Реализация Swagger на обычном веб-API возможна вручную.
Возможность публиковать свои приложения API в Azure Market Place. Azure Market Place - это общедоступный репозиторий для всех приложений API, которые можно использовать бесплатно или за плату.
это 15-минутное видео с канала Channel 9 дает отличный обзор приложений Api.
Чтобы дополнить ответ Грега, вот еще более свежая статья с описанием различий.
Подводить итоги:
«Ключевые функции приложений API - аутентификация, метаданные CORS и API - были перенесены непосредственно в службу приложений. С этим изменением функции доступны в веб-приложениях, мобильных приложениях и приложениях API. Фактически, все три используют один и тот же Microsoft.Web / тип ресурса сайтов в диспетчере ресурсов ".
И еще одно важное замечание:
«Если ваш API уже развернут как веб-приложение или мобильное приложение, вам не нужно повторно развертывать приложение, чтобы воспользоваться преимуществами новых функций».
Это может зависеть от того, что вы пытаетесь сделать, но при создании службы вы должны использовать веб-API. Веб-API ASP.Net - это платформа для создания HTTP-служб, которые могут использоваться широким кругом клиентов. Это позволяет вам создавать его не только для веб-приложения, но и для подключения к приложениям Android, приложениям IOS, веб-приложениям, приложениям Windows 8, приложениям WPF и т. Д.
Поэтому, если вам нужна веб-служба, но не нужен протокол SOAP, вы можете использовать веб-API.
Вот мои комментарии:
Приложение API: используется для определенных функций. Запуск этой функции по URL-адресу. Может использоваться с GET, POST, PUT, DELETE. Может получать параметры в BODY (Json). Ответ с действительным кодом состояния (сбой, успех.)
Веб-приложение: приложение, развернутое с множеством функций, например каталог для создания, обновления и удаления клиентов или для создания полной ERP.
Функция APP: очень похожа на приложение API, используется для определенных функций. Запуск этой функции по URL-адресу. Может использоваться с GET, POST, PUT, DELETE. Может получать параметры в BODY (Json). Ответ с действительным кодом состояния (сбой, успех.)
Фактически вы можете развернуть свой aspnet webapi в Azure WebApp и самостоятельно разместить в рабочих ролях.
В WebApp (бывшие веб-сайты Azure) он будет развернут в IIS, чтобы вы могли воспользоваться функциями IIS.