Чому для Web Api не існує підтримки типу WSDL?

Тож я тільки розпочинаю роботу з .Net WebApi, і одне, що я помічаю відразу, - це те, що немає договору, який визначав би, як API виглядає і який слід споживати (Запит / Відповіді від кожної дії), як правило, це у формі WSDL для WCF / мила.

Мені здається, що це щось, що було б дуже цінним і значно полегшило життя споживачам вашого API.

Чи є причина, що її немає? Чи є парадигма програмування або принцип, про який я не знаю? Чи є спосіб я створити його?

Мило, відпочинок та творчість людей

SOAP потребує описового документа, як WSDL, оскільки кожен ресурс може використовуватися з різними повідомленнями, в протоколі немає визначення про обмеження можливих імен / повідомлень, якими можна маніпулювати ресурсом.

Наприклад, в SOAP ваша веб-служба, яка дозволяє клієнтам маніпулювати користувачем, може викрити операцію, яка створює користувача у багатьох різних повідомленнях, наприклад:

addUser
createUser
insertUser

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

З іншого боку, якщо ви відкриваєте свою базову систему за допомогою веб-api, який дійсно дотримується принципів REST, клієнту просто потрібно знати, що у вас є ресурс з ім'ям Користувачі, оскільки є 99% шансів, що ви можете створити користувача в цьому шлях

POST /Users

І це відбувається для кожної операції, яку ви хочете викрити за допомогою SOAP або веб-програми REST.

Незважаючи на те, що SOAP є протоколом, який обмежує те, що ви можете чи не можете робити, і бути REST стильовою архітектурою, яка залишає багато відкритих моментів того, як робити. Докладаються зусилля для визначення умов щодо викриття та споживання веб-apst REST.

ОПИСАННЯ ВІДПРИЄМСТВА WEB API

У полі, як описати веб-api REST, я можу навести Swagger . Це не спроба створити WSDL, як веб-api REST, але це хороша спроба створити відкритий стандарт для опису веб-apis REST.

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

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

Існує багато реалізацій Swagger для більшості мов: C #, Java, Python, Ruby тощо.

Якщо ви використовуєте веб-API ASP .NET, є кілька проектів для автоматичного створення специфікації Swagger, як-от Swagger.NET

УЗАГАЛЬНЕННЯ КЛІЄНТІВ НА ВІДПОВІДАЛЬНІСТЬ WEB API

Тому що обмеження REST, як і обмежений набір дієслів (GET, POST, PUT, DELETE тощо), не є настільки складним для створення клієнтської бібліотеки до веб-програми REST.

Такі проекти, як WebApiProxy, можуть з легкістю створювати клієнтів на C # і Javascript.

КОНВЕНЦІЇ ДЛЯ ВЕБ-API REST

Щоб зробити життя нашим розробникам легше, добре визначимося з деякими умовами того, як буде вести себе наш веб-api REST, найкращі зусилля, які я знаю в цій галузі, - це дуже хороша електронна книга Apigee - Web Api Design . Електронна книга - це не спроба створити біблію чи мантру про те, як розробити свій api, а скоріше колекцію конвенцій, що спостерігаються у великих веб-афішах REST, таких як Twitter, Facebook, Linkedin, Google тощо.

Коротше кажучи, тому що SOAP був розроблений як самоописний: кінцева точка SOAP зазвичай включає wsdl, який описує, які операції вони надають, і як виглядають дані (за допомогою вбудованих XSD), які кожна операція приймає та / або повертає.
Завдяки такій самоописуваності програма, наприклад Visual Studio, може генерувати для неї проксі-сервіс.

Крім того, існує кілька розширень SOAP (специфікації WS-*), які дозволяють використовувати шифрування чи транзакційну поведінку з SOAP. Ідея полягає в тому, що ви можете використовувати SOAP в якості єдиного магазину для створення корпоративних веб-сервісів.

З іншої сторони...

WebAPI призначений для надання послуг REST. Формат зв'язку для REST зазвичай JSON або звичайний xml - хоча це насправді не має значення, це може бути навіть звичайний текст. Послуги REST дотримуються зовсім іншої філософії: вони призначені для легкої ваги, щоб їх легко споживали сценарії на стороні клієнта як частина рішення AJAX або мобільні пристрої.
Таким чином, існує необхідність звести рівень церемонії до мінімуму, включаючи самоописність. Крім того, навіть якщо ви цього хотіли, більшість форматів зв'язку, які використовуються в службах REST (наприклад, JSON), так і не мають формального способу опису їх вмісту.

Підводячи підсумок, можна сказати, що веб-сервіси SOAP зазвичай використовуються для інтеграції (можливо, розрізнених) рішень, тоді як послуги REST краще підходять для забезпечення зв'язку між частинами того самого рішення.

API SOAP / WS- * та RESTful не однакові. Якщо ви хочете створити API, що підтримують SOAP / WS- * WSDL, інструментом вибору в стеку Microsoft є WCF, встановлений з можливістю прив’язки HTTP (є параметри прив'язки XML та JSON, XML - опція підтримки WSDL).

На практиці використання WSDL з іншої мови впровадження або платформи було проблематичним. WS- * шари безпеки над верхом тим більше.

Мій власний досвід в основному стосувався .Net, Node, Java та PHP в цьому відношенні, і я можу сказати, що коли у вас є платформи, які не повинні визначати деталі дочірнього типу, або ви будете використовувати "Object" як Визначення, щонайменше, стає проблематичним. Крім цього, здебільшого ніхто насправді не розуміє всього SOAP / WS- *, покладаючись на інструменти, щоб змусити його працювати. Цей інструмент має багато накладних витрат, і різні системи працюють по-різному.

Ось деякі причини, за якими люди намагалися спробувати простіші реалізації. Послуги REST (ala Web API) пропонують кінцеві точки навколо об'єктів / стану. Ідея полягає в тому, що простіше визначити набір простіших об'єктних структур, представлених у форматі JSON, і кінцеві точки, які слід використовувати для цих структур, ніж намагатися використовувати WSDL з чужорідного середовища, яке не працює, а потім спробуйте викопати і обійти проблему.

Як не дивно, це одна з областей, в якій я використовував Node партії як сервіс перекладу, просто тому , що вона була досить гнучкою , щоб прийняти брудні реалізації в якості клієнта, і я міг би написати кілька простих клієнтів з моєї адаптованої корисного навантаження , яка працювала краще. EX: C # отримує текст JSON, що я використовую JSON.Net для перетворення в об'єктне представлення, яке я визначив, фактично працював, коли я не міг використовувати імпорт WSDL.

На практиці це трапляється багато.

Хоча багато відповідей тут чудові, я думаю, що відповідь набагато простіший: ви дивитесь на неправильну технологію роботи.

Якщо ви хочете створити SOAP-сервіс, вам дійсно слід дотримуватися WCF. Це все ще дуже потужна основа, Microsoft все ще активно розвиває її, жодних оголошень нам не було зроблено, щоб думати, що це відбудеться в будь-якому майбутньому, і це було зроблено з огляду на це. Web API жодним чином не витісняє WCF (хоча він, мабуть, модніший, ніж WCF).

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

Не звинувачуйте веб-API у тому, що він не дає можливості робити певні речі, для яких він не був створений.