it-swarm.com.de

Warum wird Web Api nicht vom Typ WSDL unterstützt?

Ich fange gerade erst mit .Net WebApi an und eine Sache, die mir sofort auffällt, ist, dass es keinen Vertrag gibt, der definiert, wie die API aussieht und verwendet werden soll (Anfrage/Antworten von jeder Aktion). Dies geschieht normalerweise in Form von eine WSDL für WCF/Soap.

Es scheint mir, dass dies sehr wertvoll ist und den Verbrauchern Ihrer API das Leben erheblich erleichtert.

Gibt es einen Grund, warum es keinen gibt? Gibt es ein Programmierparadigma oder -prinzip, das mir nicht bekannt ist? Gibt es eine Möglichkeit, eine zu erstellen?

33
shenku

SOAP, REST UND KREATIVITÄT DER MENSCHEN

SOAP benötigt ein Beschreibungsdokument wie WSDL, da jede Ressource mit unterschiedlichen Nachrichten belegt werden kann. Das Protokoll enthält keine Definition für Einschränkungen der möglichen Namen/Nachrichten, mit denen Sie eine Ressource bearbeiten können.

Beispiel: In SOAP Ihr Webdienst, mit dem Clients einen Benutzer manipulieren können, kann der Vorgang, der einen Benutzer erstellt, in vielen verschiedenen Nachrichten verfügbar gemacht werden, z.

addUser
createUser
insertUser

Dies sind natürlich nur einige Beispielnachrichten, da ich viele lustige Methodennamen für Webdienste gesehen habe. Es gibt wirklich kreative Leute da draußen.

Wenn Sie andererseits Ihr zugrunde liegendes System mithilfe einer Web-API verfügbar machen, die die Prinzipien von REST] wirklich respektiert, muss der Client nur wissen, dass Sie über eine Ressource mit dem Namen Benutzer verfügen, da 99% davon vorhanden sind Chance, dass Sie auf diese Weise einen Benutzer erstellen können

POST /Users

Dies geschieht für jede Operation, die Sie mit SOAP oder einem Web-API-REST) ​​verfügbar machen möchten.

Obwohl es sich um SOAP ein Protokoll handelt, das einschränkt, was Sie tun können oder nicht, und REST eine Stilarchitektur, die viele offene Punkte für die Vorgehensweise lässt) Es gibt Bestrebungen, Konventionen zu definieren, wie man REST Web-Apis) verfügbar macht und konsumiert.


BESCHREIBEN EINES WEB-API-RESTES

Im Bereich der Beschreibung einer Web-API REST Ich kann Swagger zitieren. Es ist kein Versuch, eine WSDL zu erstellen, die der Web-API-REST ähnelt, aber es ist Ein guter Versuch, einen offenen Standard für die Beschreibung von Web-API-REST zu erstellen.

Swagger ist eine Spezifikation und vollständige Framework-Implementierung zum Beschreiben, Produzieren, Konsumieren und Visualisieren von RESTful-Webdiensten.

Ich benutze Swagger sehr oft und liebe es wirklich, hauptsächlich weil Swagger UI , mit dem Sie eine schöne Live-Konsole und Dokumentation für Ihre Web-API erstellen können.

Es gibt viele Implementierungen von Swagger für die meisten Sprachen: C #, Java, Python, Ruby usw.

Wenn Sie die Web-API ASP .NET) verwenden, gibt es einige Projekte zum automatischen Generieren der Swagger-Spezifikation, z. B. Swagger.NET


KUNDEN FÜR EINEN WEB-API-REST ERZEUGEN

Da die Einschränkungen von REST, wie die begrenzte Anzahl von Verben (GET, POST, PUT, DELETE usw.), nicht so schwierig sind, eine Clientbibliothek für eine Web-API-REST zu generieren.

Projekte wie WebApiProxy können problemlos Clients mit C # und Javascript generieren.


KONVENTIONEN FÜR WEB API REST

Um unser Leben als Entwickler einfacher zu halten, ist es gut, einige Konventionen für das Verhalten unserer Web-API zu definieren REST, die beste Anstrengung, die ich in diesem Bereich kenne, ist die sehr gute Apigee - Web-API) Design ebook . Das E-Book ist kein Versuch, eine Bibel oder ein Mantra zum Entwerfen Ihrer API zu erstellen, sondern eine Sammlung von Konventionen, die im großen Web eingehalten werden REST apis, wie Twitter, Facebook, Linkedin, Google usw.

23
giacomelli

Kurz gesagt, weil SOAP so konzipiert wurde, dass es selbstbeschreibend ist: Ein SOAP Endpunkt enthält normalerweise eine WSDL, die beschreibt, welche Operationen er bereitstellt und wie die Daten aussehen (mittels Embedded) XSDs), die jede Operation benötigt und/oder zurückgibt.
Aufgrund dieser Selbstbeschreibung ist es einer Anwendung wie Visual Studio möglich, einen Webservice-Proxy dafür zu generieren.

Darüber hinaus gibt es mehrere Erweiterungen für SOAP (die WS- * -Spezifikationen), mit denen Verschlüsselung oder Transaktionsverhalten mit SOAP verwendet werden können. Die Idee ist, dass Sie SOAP als One-Stop-Shop verwenden können, um Webservices für Unternehmen zu erstellen.

Auf der anderen Seite...

WebAPI wurde entwickelt, um REST Dienste bereitzustellen. Das Kommunikationsformat für REST ist normalerweise JSON oder einfaches XML - obwohl es wirklich keine Rolle spielt, kann es sogar einfacher Text sein. REST Dienste folgen einer völlig anderen Philosophie: Sie sollen leichtgewichtig sein, damit sie problemlos von clientseitigen Skripten als Teil einer AJAX Lösung oder von Mobilgeräten verwendet werden können.
Daher ist es notwendig, das Niveau der Zeremonie auf ein Minimum zu beschränken, einschließlich der Selbstbeschreibung. Selbst wenn Sie dies möchten, haben die meisten Kommunikationsformate, die in REST -Diensten verwendet werden (z. B. JSON), ohnehin keine formale Möglichkeit, deren Inhalt zu beschreiben.

Zusammenfassend könnte man sagen, dass SOAP Webservices normalerweise zum Integrieren (möglicherweise unterschiedlicher) Lösungen verwendet werden, während REST Services besser für die Kommunikation zwischen Teilen derselben Lösung geeignet sind.

5
Astrotrain

SOAP/WS- * und RESTful APIs sind nicht identisch. Wenn Sie SOAP/WS- * WSDL-unterstützende APIs erstellen möchten, ist WCF das bevorzugte Tool im Microsoft-Stack, das mit einer HTTP-Bindungsoption bereitgestellt wird (es gibt XML- und JSON-Bindungsoptionen, wobei XML die WSDL-unterstützende Option ist).

In der Praxis war es problematisch, eine WSDL aus einer anderen Implementierungssprache oder -plattform zu verwenden. WS- * Sicherheitsschichten übertrieben noch mehr.

Meine eigenen Erfahrungen habe ich hauptsächlich mit .Net, Node, Java und PHP in dieser Hinsicht) gemacht, und das kann ich sagen, wenn Sie Plattformen haben, die dies nicht tun Wenn Sie die Details eines untergeordneten Typs definieren müssen oder "Objekt" als Definition verwenden, wird es gelinde gesagt problematisch. Darüber hinaus versteht größtenteils niemand wirklich alles von SOAP/WS- *, das sich stark auf Werkzeuge stützt Damit es funktioniert. Dieses Werkzeug hat viel Aufwand und verschiedene Systeme arbeiten unterschiedlich.

Dies sind einige der Gründe, warum Menschen nach einfacheren Implementierungen suchten. REST Services (ala Web API) bieten Endpunkte um Objekte/Status. Die Idee ist, dass es einfacher ist, eine Reihe einfacherer Objektstrukturen im JSON-Format zu definieren und die Endpunkte für diese Strukturen zu verwenden als Es geht darum, WSDL aus einer fremden Umgebung zu verwenden, die nicht funktioniert, und dann zu versuchen, das Problem zu untersuchen und zu umgehen.

Ironischerweise ist dies einer der Bereiche, in denen ich Node in einem Los als Übersetzungsdienst verwendet habe, einfach weil er flexibel genug war, um schmutzige Implementierungen als Client zu akzeptieren und ich könnte einfache Clients für meine angepasste Nutzlast schreiben, die besser funktioniert. EX: C # ruft JSON-Text ab, den ich mit JSON.Net in eine von mir definierte Objektdarstellung konvertiere, die tatsächlich funktioniert hat, wenn ich keinen WSDL-Import verwenden konnte.

In der Praxis passiert dies sehr oft.

1
Tracker1