Servizi RESTful - Equivalente WSDL

Question

Ho letto REST e SOAP e ho capito perché l'implementazione di REST può essere utile per l'utilizzo di un protocollo SOAP. Tuttavia, continuo a non capire perché non ci sia l'equivalente "WSDL" nel mondo REST. Ho visto post dire che non c'è "bisogno" per il WSDL o che sarebbe ridondante nel mondo REST, ma non capisco perché. Non è sempre utile associarsi in modo programmatico a una definizione e creare classi proxy invece della codifica manuale? Non intendo entrare in un dibattito filosofico, cercando solo il motivo per cui non c'è WSDL in REST, o perché non è necessario. Grazie.

Answer 1

Il Web Application Description Language (WADL) è fondamentalmente l'equivalente di WSDL per i servizi RESTful ma c'è stata una controversia in corso se è necessario qualcosa del genere.

Joe Gregorio ha scritto a nice article about that topic che vale la pena leggere.

Answer 2

WSDL descrive gli endpoint di servizio. I client REST non devono essere accoppiati agli endpoint del server (ovvero non dovrebbero essere a conoscenza degli URL in anticipo). I client REST sono accoppiati sui tipi di media che vengono trasferiti tra client e server.

Potrebbe avere senso generare automaticamente classi sul client per avvolgere i tipi di media restituiti. Tuttavia, non appena inizi a creare classi proxy attorno alle interazioni di servizio, inizi a oscurare le interazioni HTTP e rischia di degenerare verso un modello RPC.

Answer 3

WSDL is extensible to allow description of endpoints and their messages regardless of what message formats or network protocols are used to communicate

Tuttavia, RIPOSO utilizza il protocollo di rete utilizzando verbi HTTP e URI per rappresentare uno stato oggetti.

I WSDL ti dicono in questo luogo, se invii questo messaggio, eseguirai questa azione e otterrai di conseguenza questo formato.

In REST, se avessi voluto creare un nuovo profilo userei il verbo POST con un corpo JSON o variabili del server HTTP che descrivono il mio profilo all'URL /profile

POST dovrebbe restituire un lato server generato ID, utilizzando il codice di stato 201 CREATED e l'intestazione Location: *new_profile_id* (ad esempio 12345)

posso quindi eseguire gli aggiornamenti che cambiano lo stato del /profile/12345 utilizzando il verbo HTTP POST, dire di cambiare il mio addresss e-mail o numero di telefono. Ovviamente cambiando lo stato dell'oggetto remoto.

GET sarebbe restituire lo stato attuale del /profile/12345

PUT viene di solito utilizzato per lato client generato ID

DELETE, ovvio

HEAD, ottiene lo stato, senza la restituzione del corpo.

Con REST dovrebbe essere auto-documentante tramite un'API ben progettata e quindi più facile da usare.

This is a great article su REST. Mi aiuta davvero a capirlo anche io.

Answer 4

Il linguaggio di descrizione dell'applicazione Web (WADL) è un vocabolario XML utilizzato per descrivere i servizi Web RESTful.

Come con WSDL, un client generico può caricare un file WADL e essere immediatamente equipaggiato per accedere a tutte le funzionalità del servizio Web corrispondente.

Poiché i servizi RESTful hanno interfacce più semplici, WADL non è quasi necessario per questi servizi, poiché WSDL è per i servizi SOAP in stile RPC.

Answer 5

Esiste un RSDL (linguaggio di descrizione del servizio restful) che è equivalente a WSDL. L'URL sotto descrive la sua pratica http://en.wikipedia.org/wiki/HATEOAS e http://en.wikipedia.org/wiki/RSDL. Il problema è che abbiamo un sacco di strumenti per generare codice da wsdl a java o viceversa. Ma non ho trovato nessuno strumento per generare codice da RSDL.

Answer 6

RSDL si propone di girare a riposo come un ipermedia, in altre parole, ha più informazioni di un descrittore di servizi come WSDL o WADL. Ad esempio, ha le informazioni sulla navigazione, come l'ipertesto e i collegamenti ipertestuali.

Ad esempio, data una risorsa corrente, si dispone di un set di collegamenti os ad altre risorse correlate.

Tuttavia, non ho trovato Rest Client che supporta questo formato o Rest Server Solutions con una funzionalità per generarlo automaticamente.

Penso che ci sia una lunga strada per una conclusione al riguardo. Vedi la lunga storia HTML e W3C vs Browser lol.

Per maggiori dettagli su Resto come Hypermedia cercarlo: http://en.wikipedia.org/wiki/HATEOAS

Nota: Roy Fielding è stato criticato queste tendenze in API REST senza l'approccio hypermidia: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

La mia conclusione: ora un giorno, WADL è più comune che i framework di Rest and Integration come Camel CXF supportano già WADL (generare e consumare), perché è simile a WSDL, quindi è più facile da capire in questo processo di migrazione (da SOAP a REST).

Vediamo nei prossimi capitoli;)

Answer 7

WSDL specifica 2.0 ha aggiunto il supporto per i servizi web REST troppo. Il meglio dello scenario di entrambi i mondi. Il problema è che WSDL 2.0 non è ampiamente supportato dalla maggior parte degli strumenti disponibili. WSDL 2.0 è raccomandato W3C, WSDL1.1 non è raccomandato dal W3C ma ampiamente supportato da strumenti e sviluppatori. Rif: http://www.ibm.com/developerworks/library/ws-restwsdl/

Answer 8

Non è sempre utile per legare di programmazione per una definizione e creare classi proxy invece che manualmente codifica?

D'accordo con tutto il cuore, questo è il motivo per cui ho usato personalmente Swagger.io

Swagger è un potente framework open source sostenuta da un grande ecosistema di strumenti che consente di progettare, costruire, documentare e consumano le tue API RESTful.

Quindi, in pratica io uso Swagger per descrivere i miei modelli, endpoint, ecc, e poi io uso altri strumenti come swagger-codegen per generare le classi proxy invece di codificare manualmente.

Vedere anche: RAML