Per i servizi Web SOAP esiste una specifica che deve essere seguita da tutte le richieste/risposte. Questa specifica è sotto forma di un documento WSDL. Tuttavia, per i servizi Web REST, perché non esiste tale specifica o WSDL? Questo rende REST più vulnerabile alle eccezioni del runtime perché non stiamo seguendo alcuna specifica?Perché REST non ha un WSDL diverso dal SOAP
REST in realtà utilizza solo i verbi HTTP (GET, PUT, POST, DELETE, ...) su una risorsa. Tutte le operazioni su una risorsa dovrebbero essere rappresentate in questo modo. POST viene utilizzato come un punto di riferimento per tutti quando non è possibile esprimere la logica aziendale in un modo che si adatta agli altri tre. Questo è il motivo per cui non esiste in realtà un WSDL per un servizio REST poiché hai sempre solo 4 metodi sulla risorsa.
Ma hai ancora the possibility to describe a REST web service with WSDL 2.0.
ci sono sacco di modi per definire un'API RESTful proprio come WSDL per SOAP:
È possibile trovare maggiori informazioni qui su my blog post.
SOAP è un protocollo.
REST è un'architettura.
In molti riferimenti vedrete REST e SOAP entrambi menzionati come concorrenti. Quello non è vero. SOAP è in realtà un protocollo, non uno stile di architettura . Ciò che REST può essere confrontato è SOA e RPC. Tutti e tre sono esempi di stili di servizi Web, ognuno con il proprio focus concettuale . RPC è incentrato su operazioni, SOA attorno ai messaggi e REST sulle risorse. (ref)
Così per SOAP, ha scritto WSDL document standards. Ma per REST non esiste un documento standard, ma ci sono molte best practice come http://jsonapi.org
Il suggerimento che qualcosa come WSDL non sia necessario per i servizi REST a causa dell'uso dei verbi HTTP standard è fuorviante. La realtà è che in generale non è possibile contare su diverse implementazioni REST per utilizzare HTTP allo stesso modo e i verbi HTTP non ti dicono nulla delle rappresentazioni su cui agiscono. Quindi, per ogni dato servizio REST, c'è un enorme vuoto di informazioni su come usarlo, lasciando agli implementatori lo sviluppo di alcuni mezzi fuori banda per descriverlo, che vanno da "leggi la nostra documentazione" a "curiosità con il browser e capirlo ". – Hoobajoob