Servizi RESTful - Equivalente WSDL

Ho letto di REST e SOAP e capisco perché l'implementazione di REST può essere utile rispetto all'utilizzo di un protocollo SOAP. Tuttavia, continuo a non capire perché non esiste l'equivalente "WSDL" nel mondo REST. Ho visto messaggi che dicono che "non c'è bisogno" del WSDL o che sarebbe ridondante nel mondo REST, ma non capisco perché. Non è sempre utile associarsi a livello di programmazione a una definizione e creare classi proxy invece di codificare manualmente? Non intendo entrare in un dibattito filosofico, ma solo cercare il motivo per cui non c'è WSDL in REST, o perché non è necessario. Grazie.

Il linguaggio di descrizione dell'applicazione Web (WADL) è fondamentalmente l'equivalente di WSDL per i servizi RESTful, ma c'è stata una controversia in corso se qualcosa di simile sia necessario.

Joe Gregorio ha scritto un bell'articolo su questo argomento che vale la pena leggere.

WSDL descrive gli endpoint del servizio. I client REST non dovrebbero essere accoppiati agli endpoint del server (cioè non dovrebbero esserne a conoscenza in anticipo negli URL). I client REST sono accoppiati sui tipi di supporto che vengono trasferiti tra il client e il server.

Può avere senso generare automaticamente le classi sul client per avvolgere i tipi di supporto restituiti. Tuttavia, non appena inizi a creare classi proxy attorno alle interazioni del servizio, inizi a oscurare le interazioni HTTP e rischi di degenerare di nuovo verso un modello RPC.

RSDL mira a trasformare il riposo come un ipermedia, in altre parole, ha più informazioni di un descrittore di servizi come WSDL o WADL. Ad esempio, contiene le informazioni sulla navigazione, come ipertesto e collegamenti ipertestuali.

Ad esempio, data una risorsa corrente, hai un set di collegamenti del sistema operativo ad altre risorse correlate.

Tuttavia, non ho trovato Rest Clients che supportano questo formato o Rest Server Solutions con una funzione per generarlo automaticamente.

Penso che ci sia molta strada per una conclusione al riguardo. Guarda la lunga storia HTML e W3C vs Browsers lol.

Per maggiori dettagli su Rest like Hypermedia guarda: http://en.wikipedia.org/wiki/HATEOAS

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

La mia conclusione: Now a Days, WADL è più comune che Rest and Integration Frameworks come Camel CXF supporta già WADL (genera e consuma), perché è simile a WSDL, quindi più facile da capire in questo processo di migrazione (da SOAP a REST).

Vediamo i prossimi capitoli;)

Non è sempre utile associarsi a livello di programmazione a una definizione e creare classi proxy invece di codificare manualmente?

D' accordo di tutto cuore, questo è il motivo per cui uso Swagger.io

Swagger è un potente framework open source supportato da un ampio ecosistema di strumenti che ti aiuta a progettare, costruire, documentare e utilizzare le tue API RESTful.

Quindi fondamentalmente utilizzo Swagger per descrivere i miei modelli, endpoint, ecc., E poi utilizzo altri strumenti come swagger-codegen per generare le classi proxy invece di codificarle manualmente.

Vedi anche: RAML

Esiste un RSDL (Restful Service Description Language) che è equivalente a WSDL. L'URL seguente descrive la sua pratica http://en.wikipedia.org/wiki/HATEOAS e http://en.wikipedia.org/wiki/RSDL . Il problema è che abbiamo molti strumenti per generare codice da wsdl a java o viceversa. Ma non ho trovato alcuno strumento per generare codice da RSDL.

WSDL è estendibile per consentire la descrizione degli endpoint e dei loro messaggi indipendentemente dai formati dei messaggi o dai protocolli di rete utilizzati per comunicare

Tuttavia, REST utilizza il protocollo di rete utilizzando i verbi HTTP e l'URI per rappresentare uno stato degli oggetti.

I WSDL ti dicono in questo posto, se invii questo messaggio, eseguirai questa azione e come risultato otterrai questo formato.

In REST, se volessi creare un nuovo profilo, userei il verbo POSTcon un corpo JSON o variabili del server http che descrivono il mio profilo all'URL/profile

POSTdovrebbe restituire un ID generato dal lato server, utilizzando il codice di stato 201 CREATEDe l'intestazione Location: *new_profile_id*(ad esempio 12345)

Posso quindi eseguire aggiornamenti modificando lo stato di /profile/12345utilizzo del verbo HTTP POST, ad esempio per modificare i miei indirizzi e-mail o il numero di telefono. Ovviamente cambiando lo stato dell'oggetto remoto.

GET restituirebbe lo stato corrente di /profile/12345

PUT viene solitamente utilizzato per l'ID generato dal lato client

DELETE, ovvio

HEAD, ottiene lo stato senza restituire il corpo.

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

Questo è un ottimo articolo su REST. Mi aiuta davvero anche a capirlo.

La specifica WSDL 2.0 ha aggiunto il supporto anche per i servizi Web REST. Lo scenario migliore di entrambi i mondi. Il problema è che WSDL 2.0 non è ancora ampiamente supportato dalla maggior parte degli strumenti disponibili. WSDL 2.0 è consigliato da W3C, WSDL1.1 non è consigliato da W3C ma ampiamente supportato da strumenti e sviluppatori. Rif: http://www.ibm.com/developerworks/library/ws-restwsdl/

Il linguaggio WADL (Web Application Description Language) è un vocabolario XML utilizzato per descrivere i servizi Web RESTful.

Come con WSDL, un client generico può caricare un file WADL ed essere immediatamente attrezzato per accedere alla piena funzionalità del servizio web corrispondente.

Poiché i servizi RESTful hanno interfacce più semplici, WADL non è così necessario per questi servizi come WSDL lo è per i servizi SOAP in stile RPC.