WCF vs ASP.NET Web API [закрыто]


Я провел несколько месяцев, пытаясь понять концепции WCF, и недавно я разработал свое первое приложение службы WCF.

Я борюсь немного, чтобы понять все настройки в файле config.
Я не уверен в окружающей среде, но кажется, что вы можете сделать удивительные вещи с ним.

на днях я узнал, что Microsoft вышла с новой вещью под названием ASP.NET Web API.

за что я могу прочитать, что это RESTful framework, очень проста в использовании и реализации.

теперь я пытаюсь выяснить, каковы основные различия между двумя фреймворками, и если я должен попытаться преобразовать мой старый приложение-служба WCF с новым API.

может кто-нибудь, пожалуйста, помочь мне понять различия и использование каждого из них?

11 437

11 ответов:

Новый ASP.NET Web API является продолжением предыдущего WCF Web API проект (хотя некоторые из понятия изменились).

WCF был первоначально создан для включения служб на основе SOAP. Для более простых услуг RESTful или RPCish (думаю, что клиенты, такие как jQuery) ASP.NET веб-API должен быть хорошим выбором.

для нас WCF используется для SOAP и Web API для отдыха. Я хочу, чтобы веб-API поддерживал SOAP тоже. Мы не используем расширенные возможности WCF. Вот сравнение от MSDN:

enter image description here

ASP.net веб-API-это все о HTTP и REST на основе GET, POST, PUT, DELETE с well know ASP.net стиль программирования MVC и JSON returnable; web API предназначен для всех легких процессов и чистых компонентов на основе HTTP. Для одного, чтобы идти вперед с WCF даже для простой или простой одной веб-службы он принесет весь дополнительный багаж. Для легкого веса простой сервис для ajax или динамических вызовов всегда WebApi просто решает эту проблему. Это аккуратно дополняет или помогает параллельно ASP.net MVC.

Проверьте подкаст: Hanselminutes Podcast 264-это не WCF вашего отца-Все о WebAPI с Glenn Block Скотт Хансельман для получения дополнительной информации.

в сценариях, перечисленных ниже, вы должны пойти на WCF:

  1. Если вам нужно отправить данные по протоколам, таким как TCP, MSMQ или MIME
  2. Если потребляющий клиент просто знает, как потреблять сообщения SOAP

WEB API-это платформа для разработки служб RESTful / HTTP.

есть так много клиентов, которые не понимают мыло, как браузеры, HTML5, в этих случаях веб-API являются хорошим выбором.

заголовок служб HTTP указывает, как защитить службу, как кэшировать информацию, тип тела сообщения и тело HTTP может указывать любой тип контента, например HTML, а не только XML в качестве служб SOAP.

WCF даст вам так много из коробки, это даже не сравнимо ни с чем. Если вы не хотите делать на своей собственной реализации (чтобы назвать несколько) аутентификацию, авторизацию, шифрование, очереди, регулирование, надежный обмен сообщениями, ведение журнала, сеансы и так далее. WCF-это не [только] веб-службы; WCF-это платформа разработки для SOA.

с помощью обоих до сих пор, я нашел много различий между WCF и веб-API. Обе технологии стека хорошо подходят в разных-разных сценариях. Поэтому невозможно сказать, что лучше, это зависит от конфигурации и сценарии.

See this image to understand more differnce

Примечание: данные не только мое мнение это также собирается с другого официального сайта.

есть сравнение на MSDN об этом

WCF и ASP.NET Web API

для меня выбор был о том, кто клиенты, и где они находятся?

внутри сети компании и клиентов на основе .NET: используйте WCF с привязкой TCP (быстрая связь, чем HTTP)

за пределами корпоративной сети, и использовать разнообразные технологии, такие как PHP, Python и так далее: используйте Web API с REST

бизнес говоря, WebApi не хватает WSDL, поэтому разработчики должны документировать все вручную. И если, например, операция WebApi возвращает список объектов, то клиент должен создавать объекты вручную, т. е. WebAPI действительно подвержен ошибкам определений.

pro Webapi является его более легким, чем WCF.

Что касается заявления "WebApi не хватает WSDL" есть несколько способов для создания клиента Rest. Один из популярных подходов-Swagger UI / (Swashbukkle Nuget). Это дает богатый интерфейс для понимания схемы ввода и вывода конечной точки REST и онлайн-инструмента для тестирования конечных точек.

JSON LD (JSON Linked Documents) - это еще один новый стандарт, который еще больше улучшит опыт разработчика REST на основе JSON, предоставив схему JSON с лучшей семантикой.

Почему я отвечаю:

Я взял огромное количество времени, чтобы понять разницу между этими двумя технологиями. Я поставлю здесь все те точки, которые я думаю: "если бы у меня были эти точки в то время, когда я задавался вопросом в поисках этого ответа, то я решил очень раньше выбрать свою необходимую технологию."

источник информации:

Microsoft® Visual Studio® 2015 Unleashed

ISBN-13: 978-0-672-33736-9 ISBN-10: 0-672-33736-3

Почему ASP.NET Web API и WCF:

перед сравнением технологий ASP.NET Web API и WCF, важно понимать, что на самом деле существует два стиля/стандарта для создания веб-служб: REST (Representational State Transfer) и SOAP/WSDL. SOAP/WSDL был оригинальным стандартом, на котором были построены веб-службы. Тем не менее, он был труден в использовании и имел громоздкие форматы сообщений (например, XML), которые ухудшали производительность. Услуги на основе отдыха быстро стала альтернативой. Они легче писать, потому что они используют основные конструкции HTTP (GET, POST, PUT, DELETE) и обычно используют меньшие форматы сообщений (например, JSON). В результате службы HTTP на основе REST теперь являются стандартом для написания служб, которые строго ориентированы на веб.

давайте определим цель ASP.NET Web API

ASP.NET Web API-это технология Microsoft для разработки веб-служб HTTP на основе REST. (Он давно заменил Microsoft ASMX, который был основан на SOAP / WSDL.) Веб-API позволяет легко писать надежные службы на основе протоколов HTTP, которые понимают все браузеры и собственные устройства. Это позволяет создавать службы для поддержки вашего приложения и вызывать их из других веб-приложений, планшетов, мобильных телефонов, ПК и игровых консолей. Большинство приложений, написанных сегодня, чтобы использовать вездесущее веб-соединение, используют службы HTTP в некотором роде.

Давайте теперь определим цели WCF:

общение через Интернет не всегда является наиболее эффективным средством. Например, если и клиент, и служба существуют на одной технологии (или даже на одной машине), они часто могут договориться о более эффективных средствах связи (таких как TCP/IP). Разработчики сервиса обнаружили, что делают тот же выбор, которого они пытались избежать. Теперь им придется выбирать между созданием эффективных внутренних служб и возможностью иметь широкий доступ к ним интернет. И, если они должны поддерживать оба, они, возможно, придется создать несколько версий своей службы или по крайней мере отдельные прокси для доступа к их обслуживанию. это проблема, которую Microsoft решила с помощью WCF.

С WCF, вы можете создать свой сервис, не заботясь о границах. Затем вы можете позволить WCF беспокоиться о запуске службы наиболее эффективным способом, в зависимости от вызывающего клиента. Для управления этой задачей WCF использует концепцию конечных точек. Ваш служба может иметь несколько конечных точек (настраивается во время разработки или после развертывания). Каждая конечная точка указывает, как служба может поддерживать вызывающий клиент: через Интернет, через удаленное взаимодействие, через очередь сообщений Microsoft (MSMQ) и многое другое. WCF позволяет сосредоточиться на создании функциональных возможностей службы. Он беспокоится о том, как наиболее эффективно говорить с вызовом клиентов. Таким образом, Единая служба WCF может эффективно поддерживать множество различных типов клиентов.

пример WCF:

Рассмотрим пример:

данные клиента совместно используются между приложениями. Каждое приложение может быть написано на другой платформе, и она может существовать в другом месте. Интерфейс клиента можно извлечь в службу WCF, которая предоставляет общий доступ к общим данным клиента. Это централизует данные, уменьшает дублирование, исключает синхронизацию и упрощает управление. Кроме того, с помощью WCF, можно настроить конечные точки службы работать так, как это имеет смысл для вызывающего клиента. На рисунке показан пример ранее с централизованным доступом к данным клиента в службе WCF.

This is how WCF serves different clients

вывод:

i) когда выбрать Web API:

нельзя отрицать, что REST-службы HTTP, такие как созданные с помощью ASP.NET веб-API стали стандартом для построения веб-сервисов. Эти услуги предлагают простой и понятный подход для web разработчики строительных услуг. Веб-разработчики понимают HTTP GET и POST и, таким образом, хорошо адаптируются к этим типам услуг. Поэтому, если вы пишете услуги строго нацелены на HTTP, ASP.NET веб-API является логическим выбором.

ii) Когда выбрать WCF:

технология WCF полезна, когда необходимо поддерживать несколько конечных точек службы на основе различных протоколов и форматов сообщений. Такие продукты, как Microsoft BizTalk leverage WCF для создания надежных сервисов, которые могут быть использованы через Интернет, а также с помощью различных конфигураций машина-машина.Если, однако, вам нужно написать приложение, которое взаимодействует по TCP / IP при подключении к локальной сети и работает по HTTP, когда вне сети, WCF-это ваш ответ.

Предупреждение:

веб-разработчики часто рассматривают WCF как более сложный и сложный для разработки. Поэтому, если вы не предвидите необходимость в мультипротоколе услуги, которые вы, вероятно, придерживаетесь ASP.NET Web API.

с помощью wcf мы можем настроить и предоставить одинаковую поддержку службы для нескольких конечных точек, таких как tcp, http.если вы хотите, чтобы ваш сервис был основан только на http, тогда лучше будет пойти с веб-API. Web API имеет очень меньшую конфигурацию по сравнению с wcf и немного быстрее, чем wcf. Wcf также поддерживает службы restful. Если у вас есть ограничение .Net framework 3.5, то ваш вариант-wcf.