Perché non esiste un supporto del tipo WSDL per Web Api?

Quindi sto appena iniziando con .Net WebApi e una cosa che sto notando immediatamente è che non esiste un contratto che definisce l'aspetto dell'API e che dovrebbe essere consumato (richiesta / risposte da ogni azione), questo di solito è sotto forma di un WSDL per WCF / sapone.

Mi sembra che questo sia qualcosa che sarebbe molto prezioso e renderebbe la vita molto più facile per i consumatori della tua API.

C'è un motivo per cui non ce n'è uno? Esiste un paradigma o principio di programmazione di cui non sono a conoscenza? C'è un modo per crearne uno?

CREATIVITÀ DI SAPONE, RESTO E PERSONE

SOAP ha bisogno di un documento di descrizione come WSDL perché ogni risorsa può essere consumata con messaggi diversi, non ci sono definizioni sul protocollo sui vincoli ai possibili nomi / messaggi che è possibile manipolare una risorsa.

Ad esempio, in SOAP il servizio Web che consente ai client di manipolare un utente può esporre l'operazione che crea un utente in molti messaggi diversi, come:

addUser
createUser
insertUser

Naturalmente, questi sono solo alcuni messaggi di esempio, perché ho visto molti nomi di metodi di servizi Web divertenti. Ci sono persone davvero creative là fuori.

D'altra parte, se stai esponendo il tuo sistema sottostante usando API Web che rispettano davvero i principi REST, il cliente deve solo sapere che hai una risorsa chiamata Users, perché c'è il 99% di probabilità che tu possa creare un utente in questo modo

POST /Users

E questo si verifica per ogni operazione che si desidera esporre utilizzando SOAP o un REST di API Web.

Nonostante sia un protocollo SOAP, che limita ciò che puoi o non puoi fare ed essere REST un'architettura di stile, che lascia molti punti aperti su come fare le cose. Ci sono sforzi per definire convenzioni su come esporre e consumare le API web REST.

DESCRIVERE UN RESTO API WEB

Nel campo di come descrivere un web api REST posso citare Swagger . Non è un tentativo di creare un WSDL come il web api REST, ma è un buon tentativo di creare uno standard aperto per la descrizione del web apis REST.

Swagger è una specifica e un'implementazione completa del framework per la descrizione, la produzione, il consumo e la visualizzazione di servizi Web RESTful.

Uso Swagger molto e lo adoro davvero, principalmente perché l' interfaccia utente di Swagger ti consente di generare una bella console dal vivo e documentazione per la tua API web.

Esistono molte implementazioni di Swagger per la maggior parte delle lingue: C #, Java, Python, Ruby, ecc.

Se si utilizza l'API Web ASP .NET, alcuni progetti generano automaticamente la specifica Swagger, come Swagger.NET

GENERAZIONE DI CLIENTI A UN RESTO API WEB

Perché i vincoli di REST, come l'insieme limitato di verbi (GET, POST, PUT, DELETE, ecc.) Non è così difficile da generare una libreria client in un REST di API Web.

Progetti come WebApiProxy possono facilmente generare client con C # e Javascript.

CONVENZIONI PER IL RESTO DELL'API WEB

Per semplificare la vita degli sviluppatori, è bene definire alcune convenzioni su come si comporterà il nostro REST di api Web, lo sforzo migliore che conosco in questo campo è l'ottimo e- book di Apigee - Web Api Design . L'e-book non è un tentativo di creare una bibbia o un mantra su come progettare la tua api, ma piuttosto una raccolta di convenzioni osservate nelle API REST di grandi dimensioni del web, come Twitter, Facebook, Linkedin, Google, ecc.

In breve, perché SOAP è stato progettato per essere auto-descrittivo: un endpoint SOAP di solito include un wsdl che descrive quali operazioni fornisce e come appaiono i dati (tramite XSD incorporati) che ciascuna operazione prende e / o restituisce.
A causa di questo auto-descrittivo, è possibile che un'applicazione come Visual Studio generi un proxy webservice per esso.

Inoltre, esistono diverse estensioni di SOAP (le specifiche WS- *) che consentono di utilizzare la crittografia o il comportamento transazionale con SOAP. L'idea è che puoi usare SOAP come sportello unico per creare servizi web di livello aziendale.

D'altro canto...

WebAPI è progettato per fornire servizi REST. Il formato di comunicazione per REST è di solito JSON o xml semplice - anche se in realtà non importa, potrebbe anche essere un semplice testo. I servizi REST seguono una filosofia completamente diversa: sono pensati per essere leggeri in modo da poter essere facilmente consumati dagli script lato client come parte di una soluzione AJAX o da dispositivi mobili.
Pertanto, è necessario ridurre al minimo il livello della cerimonia, compresa l'autodescrizione. Inoltre, anche se lo volessi, la maggior parte dei formati di comunicazione utilizzati nei servizi REST (come JSON) non ha comunque un modo formale di descriverne il contenuto.

Riassumendo, si potrebbe dire che i servizi Web SOAP sono generalmente utilizzati per integrare soluzioni (possibilmente disparate), mentre i servizi REST sono più adatti a fornire comunicazione tra parti della stessa soluzione.

Le API SOAP / WS- * e RESTful non sono uguali. Se si desidera creare API di supporto SOAP / WS- * WSDL, lo strumento prescelto nello stack Microsoft è WCF, montato con un'opzione di associazione HTTP (esistono opzioni di associazione XML e JSON, XML essendo l'opzione di supporto WSDL).

In pratica, l'utilizzo di un WSDL da un linguaggio o una piattaforma di implementazione diversi è stato problematico. WS- * livelli di sicurezza sopra le righe ancora di più.

La mia esperienza è stata principalmente con .Net, Node, Java e PHP a questo proposito, e posso dire che quando si hanno piattaforme che non devono definire i dettagli di un tipo figlio, o useranno "Oggetto" come definizione, diventa a dir poco problematico. Oltre a questo, per la maggior parte nessuno capisce davvero tutto di SOAP / WS- * facendo affidamento pesantemente sugli strumenti per farlo funzionare. Questa attrezzatura ha un sacco di costi generali e diversi sistemi funzionano in modo diverso.

Questi sono alcuni dei motivi per cui le persone hanno cercato di provare implementazioni più semplici. I servizi REST (ala Web API) offrono endpoint attorno a oggetti / stato. L'idea è che è più facile definire un insieme di strutture di oggetti più semplici rappresentate in formato JSON e gli endpoint da utilizzare contro queste strutture piuttosto che cercare di usare WSDL da un ambiente alieno che non funziona, quindi provare a scavare e aggirare il problema.

Ironia della sorte, questa è una delle aree in cui ho usato Node molto come servizio di traduzione, semplicemente perché era abbastanza flessibile da accettare implementazioni sporche come client e potevo scrivere semplici client sul mio carico utile adattato che funzionava meglio. EX: C # ottiene il testo JSON, che uso JSON.Net per convertire in una rappresentazione di oggetto che ho definito funzionava quando non potevo usare un'importazione WSDL.

In pratica questo succede molto.

Mentre molte delle risposte qui sono ottime, penso che la risposta sia MOLTO più semplice: stai cercando la tecnologia sbagliata per il lavoro.

Se stai cercando di creare un servizio SOAP, dovresti davvero attenerti a WCF. È ancora un framework molto potente, Microsoft lo sta ancora sviluppando attivamente, non ci sono stati annunci per farci pensare che andrà ovunque in futuro, ed è stato fatto pensando a questo. L'API Web non sostituisce in alcun modo WCF (sebbene sia probabilmente più alla moda di WCF).

L'API Web faceva parte di WCF, ma è stata spostata nella famiglia ASP.NET esattamente PERCHÉ non si adattava perfettamente alle altre tecnologie WCF. L'API Web è molto più interessata all'uso dell'HTTP come protocollo applicativo rispetto a un protocollo di trasferimento. Nell'API Web, i verbi HTTP sono re, in WCF HTTP serve semplicemente per abilitare il protocollo SOAP.

Non incolpare l'API Web per non aver dato la possibilità di fare determinate cose per le quali non è stato creato.