RESTful Services - WSDL-Äquivalent


94

Ich habe über REST und SOAP gelesen und verstehe, warum die Implementierung von REST gegenüber der Verwendung eines SOAP-Protokolls von Vorteil sein kann. Ich verstehe jedoch immer noch nicht, warum es in der REST-Welt kein "WSDL" -Äquivalent gibt. Ich habe Beiträge gesehen, in denen gesagt wurde, dass die WSDL "nicht erforderlich" ist oder dass sie in der REST-Welt überflüssig wäre, aber ich verstehe nicht, warum. Ist es nicht immer nützlich, programmgesteuert an eine Definition zu binden und Proxy-Klassen zu erstellen, anstatt sie manuell zu codieren? Ich möchte nicht in eine philosophische Debatte geraten, sondern nur nach dem Grund suchen, warum es in REST keine WSDL gibt oder warum sie nicht benötigt wird. Vielen Dank.


4
Ich habe die gleiche Frage. Aus Kundensicht scheinen erholsame Dienste viel schwieriger zu verwenden als ein WSDL-Dienst.
w.donahue

4
Es scheint mir, dass Sie keine WADL oder WSDL benötigen, wenn Sie etwas Einfaches verfügbar machen. Aber wenn Sie etwas so Komplexes wie SAP verfügbar machen ... kann ich mir nicht vorstellen, dass es keine Reflexion und keinen Namespace gibt, um mit der Fülle an Funktionen fertig zu werden.
Brain2000

Könnte die HTTP OPTIONS-Methode nicht als "äquivalent" angesehen werden, da sie Informationen zu den verfügbaren Methoden und Parametern liefern sollte, die für eine mögliche Aktion erforderlich sind?
Dim13i

Antworten:


44

Die Web Application Description Language (WADL) entspricht im Grunde der WSDL für RESTful-Dienste, es wurde jedoch kontrovers diskutiert, ob so etwas überhaupt erforderlich ist.

Joe Gregorio hat einen schönen Artikel über dieses Thema geschrieben, der eine Lektüre wert ist.


1
Danke Joschi. Ich habe die Artikel gelesen, fand aber die zweite nicht allzu überzeugend. Welche Punkte, die er anspricht, fanden Sie am wertvollsten?
Skaz

1
Es kann erwähnenswert sein, dass .NET auch eine Möglichkeit zum Veröffentlichen von Metadaten bietet ( msdn.microsoft.com/en-us/library/ms730243.aspx ). Vor diesem Hintergrund enthalten die meisten REST-Services, die von den großen Websites entwickelt wurden, eine Vielzahl von herunterladbaren Clients, die für die wichtigsten Programmiersprachen (Java, .NET, PHP usw.) entwickelt wurden. Meiner Meinung nach belastet dies den Dienstleister sehr.
Dana

4
@dana: Scheint nicht viel Sinn beim Schreiben eines Dienstes, bei dem Sie dann auch den Client schreiben müssen?
BlueChippy

19

WSDL beschreibt Service-Endpunkte. REST-Clients sollten nicht an Serverendpunkte gekoppelt sein (dh sollten sie in URLs nicht im Voraus kennen). REST-Clients sind an die Medientypen gekoppelt, die zwischen Client und Server übertragen werden.

Es kann sinnvoll sein, Klassen auf dem Client automatisch zu generieren, um die zurückgegebenen Medientypen zu umschließen. Sobald Sie jedoch damit beginnen, Proxy-Klassen für die Service-Interaktionen zu erstellen, werden die HTTP-Interaktionen verdeckt und es besteht die Gefahr, dass sie wieder in Richtung eines RPC-Modells degenerieren.


4
Können Sie etwas näher darauf eingehen? Ich fürchte, ich verstehe es nicht. Vielen Dank.
Skaz

1
Proxy-Klassen bieten eine Möglichkeit zur Maschinenüberprüfung zur Kompilierungszeit. Ohne sie haben Sie nur manuell geschriebene Dokumente und testbasierte "Validierung".
Eric Grange

1
@EricGrange ... und dennoch hat dieser Ansatz für das Web bisher ziemlich gut funktioniert.
Darrel Miller

1
@DarrelMiller hängt davon ab, was Sie als "gut funktioniert" bezeichnen. Dies ist wie in den 80er Jahren, als jeder seine Interops aus Papierdokumenten schrieb, also funktioniert es, aber "gut"?
Eric Grange

4
@BlueChippy Medienspezifikationen werden auf altmodische Weise behandelt. Sie finden entweder einen vorhandenen Parser für die Spezifikation oder Sie lesen die Spezifikation und schreiben selbst einen. Es ist wichtig zu beachten, dass das Ziel darin besteht, dass Medientypspezifikationen über APIs hinweg wiederverwendbar sind. Das Schreiben eines neuen Parsers für jede API macht den Punkt zunichte. REST, wenn es richtig gemacht wird, dient den sehr langfristigen Vorteilen einer unabhängigen Entwicklung von Client und Server.
Darrel Miller

8

RSDL zielt darauf ab, Ruhe wie ein Hypermedia zu machen, mit anderen Worten, es enthält mehr Informationen als ein Service-Deskriptor wie WSDL oder WADL. Zum Beispiel enthält es Informationen zur Navigation, wie Hypertext und Hyperlinks.

Bei einer aktuellen Ressource verfügen Sie beispielsweise über eine Reihe von OS-Links zu anderen Ressourcen.

Ich habe jedoch keine Rest-Clients gefunden, die dieses Format unterstützen, oder Rest-Server-Lösungen mit einer Funktion zum automatischen Generieren.

Ich denke, es gibt einen langen Weg für eine Schlussfolgerung. Siehe die lange HTML-Geschichte und W3C vs Browsers lol.

Weitere Informationen zu Rest like Hypermedia finden Sie unter: http://en.wikipedia.org/wiki/HATEOAS

Hinweis: Roy Fielding hat diese Tendenzen in Rest Apis ohne den Hypermidia-Ansatz kritisiert: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

Mein Fazit: WADL ist heutzutage häufiger anzutreffen als Rest- und Integrations-Frameworks wie Camel CXF, die WADL bereits unterstützen (generieren und konsumieren), da es WSDL ähnelt und daher in diesem Migrationsprozess am einfachsten zu verstehen ist (SOAP to REST).

Schauen wir uns die nächsten Kapitel an;)


8

Ist es nicht immer nützlich, programmgesteuert an eine Definition zu binden und Proxy-Klassen zu erstellen, anstatt sie manuell zu codieren?

Ich stimme voll und ganz zu, deshalb benutze ich Swagger.io

Swagger ist ein leistungsstarkes Open Source-Framework, das von einem großen Ökosystem von Tools unterstützt wird, mit denen Sie Ihre RESTful-APIs entwerfen, erstellen, dokumentieren und nutzen können.

Im Grunde genommen benutze ich Swagger, um meine Modelle, Endpunkte usw. zu beschreiben, und dann benutze ich andere Tools wie swagger-codegen , um die Proxy-Klassen zu generieren, anstatt sie manuell zu codieren.

Siehe auch: RAML


Wusste nicht, dass Swagger das auch tat. Dachte, es war nur Dokumentation / generisches Framework für REST-APIs
Robert Dundon


3

WSDL ist erweiterbar, um die Beschreibung von Endpunkten und ihren Nachrichten zu ermöglichen, unabhängig davon, welche Nachrichtenformate oder Netzwerkprotokolle für die Kommunikation verwendet werden

REST verwendet jedoch das Netzwerkprotokoll, indem HTTP-Verben und der URI verwendet werden, um einen Objektstatus darzustellen.

WSDLs sagen Ihnen an dieser Stelle, wenn Sie diese Nachricht senden, führen Sie diese Aktion aus und erhalten dieses Format als Ergebnis zurück.

Wenn ich in REST ein neues Profil erstellen wollte, würde ich das Verb POSTmit einem JSON-Body oder http-Servervariablen verwenden, die mein Profil für die URL beschreiben/profile

POSTsollte eine serverseitig generierte ID unter Verwendung des Statuscodes 201 CREATEDund des Headers zurückgeben Location: *new_profile_id*(z. B. 12345)

Ich kann dann Aktualisierungen durchführen, um den Status der /profile/12345Verwendung des HTTP-Verbs POSTzu ändern, beispielsweise um meine E-Mail-Adressen oder Telefonnummer zu ändern. Offensichtlich den Status des entfernten Objekts ändern.

GET würde den aktuellen Status des zurückgeben /profile/12345

PUT wird normalerweise für clientseitig generierte IDs verwendet

DELETE, offensichtlich

HEAD, erhält den Status, ohne den Körper zurückzugeben.

Mit REST sollte es sich über eine gut gestaltete API selbst dokumentieren und somit einfacher zu verwenden sein.

Dies ist ein großartiger Artikel über REST. Es hilft mir auch wirklich, es zu verstehen.


2
Ich würde argumentieren, dass es die Hypermedia-Einschränkung von REST ist, mehr als die einheitliche Schnittstellenbeschränkung, die die Notwendigkeit von WSDL beseitigt.
Darrel Miller

3
Wo entdecken Sie "Profil"? Wie helfen Sie, wenn Sie statt einer Dutzende haben? Alle anderen Dienste basieren auf handgeschriebenen Dokumenten und manuell geschriebenen APIs, die arbeitsintensiv und fehleranfällig sind.
Eric Grange

1
Ich stimme @EricGrange zu - können Sie bitte erklären, wie Sie wissen, auf welchen Entitäten Sie CRUD (L) -Operationen ausführen können ... es sei denn, jemand schreibt es irgendwo auf?
BlueChippy

2

Die WSDL 2.0-Spezifikation bietet auch Unterstützung für REST-Webdienste. Das Beste aus beiden Welten. Das Problem ist, dass WSDL 2.0 von den meisten Tools noch nicht allgemein unterstützt wird. WSDL 2.0 wird von W3C empfohlen, WSDL1.1 wird nicht von W3C empfohlen, wird jedoch von Tools und Entwicklern weitgehend unterstützt. Ref: http://www.ibm.com/developerworks/library/ws-restwsdl/


0

Die WADL (Web Application Description Language) ist ein XML-Vokabular zur Beschreibung von RESTful-Webdiensten.

Wie bei WSDL kann ein generischer Client eine WADL-Datei laden und sofort auf die volle Funktionalität des entsprechenden Webdienstes zugreifen.

Da RESTful-Dienste einfachere Schnittstellen haben, ist WADL für diese Dienste bei weitem nicht so notwendig wie WSDL für SOAP-Dienste im RPC-Stil.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.