RESTful Services - WSDL-Äquivalent

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.

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.

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.

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;)

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

Es gibt eine RSDL (Restful Service Description Language), die WSDL entspricht. Die folgende URL beschreibt die Vorgehensweise http://en.wikipedia.org/wiki/HATEOAS und http://en.wikipedia.org/wiki/RSDL . Das Problem ist, dass wir viele Tools haben, um Code von wsdl nach Java oder umgekehrt zu generieren. Aber ich habe kein Tool gefunden, um Code aus RSDL zu generieren.

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.

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/

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.