Я провів кілька місяців, намагаючись зрозуміти поняття, що стоять за WCF, і нещодавно я розробив своє перше додаток до служби WCF.

Я боровся, щоб зрозуміти всі налаштування у конфігураційному файлі.
Я не переконаний у навколишньому середовищі, але здається, що з ним можна робити дивовижні речі.

Днями я дізнався, що Microsoft вийшла з новою річчю під назвою ASP.NET Web API .

Що я можу прочитати, це RESTful рамки , дуже прості у використанні та реалізації.

Тепер я намагаюся розібратися, які основні відмінності між двома рамками, і якщо мені слід спробувати перетворити старий додаток служби WCF з новим API.

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

Новий веб-API ASP.NET є продовженням попереднього проекту WCF Web API (хоча деякі концепції були змінені ).

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

Для нас WCF використовується для SOAP, а веб-API для REST. Я також хочу, щоб веб-API підтримував SOAP. Ми не використовуємо розширені функції WCF. Ось порівняння з MSDN :

Веб-API ASP.net - це все про HTTP та REST на основі GET, POST, PUT, DELETE з добре відомим стилем програмування ASP.net MVC та поверненням JSON; Веб-API призначений для всіх легких процесів та чистих компонентів на основі HTTP. Для того, щоб продовжувати роботу з WCF навіть для простого чи найпростішого веб-сервісу, він принесе весь додатковий багаж. У легкій вазі просте обслуговування для ajax або динамічних дзвінків завжди WebApi просто вирішує потребу. Це акуратно доповнює або допомагає паралельно MVC ASP.net.

Ознайомтеся з подкастом: Hanselminutes Podcast 264 - Це не WCF вашого батька - Все про WebAPI з Гленном Блоком Скоттом Ханзельманом для отримання додаткової інформації.

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

1. Якщо вам потрібно надіслати дані в таких протоколах, як TCP, MSMQ або MIME
2. Якщо споживач-клієнт просто знає, як споживати SOAP-повідомлення

WEB API - це основа для розвитку RESTful / HTTP-сервісів.

Є так багато клієнтів, які не розуміють SOAP, як браузери, HTML5, і в цих випадках WEB API - хороший вибір.

Заголовок HTTP-сервісів визначає, як захистити службу, як кешувати інформацію, тип тіла повідомлення та HTTP-тіло, можна вказати будь-який тип контенту, як HTML, а не лише XML як SOAP-сервіси.

З моменту використання обох дотепер я виявив багато відмінностей між WCF та Web API. Обидва стеки технологій добре підходять до різних сценаріїв, тому неможливо сказати, що краще, це залежить від конфігурації та сценарію.

Properties              ASP.Net Web API                         WCF
--------------------------------------------------------------------------------------------------
End point (mainly)      Http based                              SOAP based
Service Type            Front End                               Back-end
Support                 caching, compression, versioning        No
Framework               ASP.net                                 WCF
Orientation             Resource Oriented                       Service Oriented
Transports              http                                    http, tcp, MSMQ, Named pipe
Message pattern         Request reply                           request Reply, one way, duplex
Configuration overhead  Less                                    Much
Security                lesser than WCF (web standard security) Very high (WS-I standard)
Hosting                 IIS                                     IIS, Windows Service, Self hosting
Performance             Fast                                    A bit slower than Web API
In use from             .NET 4.0                                .NET 3.5

Примітка. Дані - це не лише мій погляд, вони також збираються з інших офіційних веб-сайтів.

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

Чому я відповідаю:

Мені знадобилося величезна кількість часу, щоб зрозуміти різницю між цими двома технологіями. Я поставлю сюди всі ті пункти, які, на мою думку, "якби у мене були ці моменти в той час, коли я цікавився в пошуках цієї відповіді, то я вирішив дуже рано у виборі потрібної технології".

Джерело інформації:

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 (Представницький стан передачі) та SOAP / WSDL. SOAP / WSDL був оригінальним стандартом, на якому будувались веб-сервіси. Однак це було важко у використанні та мали об'ємні формати повідомлень (як XML), які погіршували продуктивність. Послуги на основі REST швидко стали альтернативою. Їх простіше писати, оскільки вони використовують основні конструкції HTTP (GET, POST, PUT, DELETE) і зазвичай використовують менші формати повідомлень (наприклад, JSON). Як результат, сервіси HTTP на основі REST тепер є стандартом для письмових сервісів, які суворо орієнтовані на Інтернет.

Давайте визначимо мету веб-API ASP.NET

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.

Висновок:

i) Коли вибрати веб-API:

Не можна заперечувати, що HTTP-сервіси на основі REST, такі як створені за допомогою веб-API ASP.NET, стали стандартом для створення веб-служб. Ці сервіси пропонують простий і простий підхід для створення веб-розробників. Веб-розробники розуміють HTTP GET та POST і тому добре адаптуються до цих типів послуг. Тому, якщо ви пишете сервіси, чітко орієнтовані на HTTP , ASP.NET Web API - це логічний вибір.

ii) Коли вибрати WCF:

Технологія WCF корисна, коли вам потрібно підтримувати декілька кінцевих точок обслуговування на основі різних протоколів та форматів повідомлень. Такі продукти, як Microsoft BizTalk, використовують WCF для створення надійних сервісів, які також можна використовувати в Інтернеті через різні конфігурації "машина-машина". Якщо, однак, вам потрібно написати програму, яка спілкується через TCP / IP, коли підключена до локальної мережі мережа та працює через HTTP, коли поза мережею WCF - це ваша відповідь .

Будьте попереджені:

Веб-розробники часто розглядають WCF як складніший і складніший для розробки. Тому, якщо ви не передбачаєте потреби в мультипротокольних послугах, ви, ймовірно, будете дотримуватися веб-API ASP.NET.

Про це існує порівняння на MSDN

WCF та ASP.NET Web API

Для мене вибір був про те, хто такі клієнти та де вони розташовані?

У межах мережі Network та клієнтів на базі .NET: Використовуйте WCF із прив'язкою TCP (швидше спілкування, ніж HTTP)

Поза межами компанії Network і використовуйте різні технології, такі як PHP, Python тощо : Використовуйте веб-API з REST

У бізнес-мові WebApi не вистачає WSDL, тому розробники повинні документувати все вручну. І якщо, наприклад, операція WebApi повертає список об'єктів, то клієнт повинен створювати об'єкти вручну, тобто WebAPI дійсно схильний до помилок визначень.

Професіонал Webapi - це його легше, ніж WCF.

Щодо твердження "WebApi не вистачає WSDL", існує кілька способів генерування решти клієнта. Один з популярних підходів - інтерфейс Swagger / (Swashbukkle Nuget). Це дає багатий інтерфейс для розуміння схеми введення та виведення кінцевої точки REST та онлайн-інструменту для перевірки кінцевих точок.

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

За допомогою wcf ми можемо налаштувати та розкрити ту саму службову підтримку для декількох кінцевих точок, таких як tcp, http. якщо ви хочете, щоб ваша послуга базувалася лише на http, тоді буде краще використовувати веб-API. Веб-API має дуже меншу конфігурацію в порівнянні з wcf і трохи швидше, ніж wcf. Wcf також підтримує спокійні послуги. Якщо у вас обмеження .Net Framework 3.5, то ваш варіант - wcf.