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

Question

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

#1 da (23 voti)
#2 da (4 voti)
#3 da (1 voti)
#4 da (-3 voti)

31

Quindi sono appena iniziato con .Net WebApi e una cosa che sto notando subito è che non esiste un Contratto che definisca l'aspetto dell'API e che dovrebbe essere consumato (Richiesta / Risposte da ciascuna Azione), questo di solito è la forma di un WSDL per WCF / Soap.

Mi sembra che questo sia qualcosa che potrebbe essere molto prezioso e rendere la vita molto più semplice per i consumatori della tua API.

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

c# asp.net-mvc web-api

posta shenku 05.08.2014 - 00:45

fonte

4 risposte

4

In breve, perché SOAP è stato progettato per essere auto-descrittivo: un endpoint SOAP di solito include un wsdl che descrive le operazioni che fornisce e come appaiono i dati (tramite XSD incorporati) che ogni operazione richiede e / o rendimenti.
A causa di questa auto-descrittività, è possibile che un'applicazione come Visual Studio generi un proxy di servizio Web per esso.

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

D'altra parte ...

WebAPI è progettato per fornire servizi REST. Il formato di comunicazione per REST è solitamente JSON o semplice xml, 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 che possano essere facilmente utilizzati dagli script lato client come parte di una soluzione AJAX o da dispositivi mobili.
In quanto tale, è necessario mantenere il livello della cerimonia al minimo, compresa l'auto-descrittività. Inoltre, anche se lo si desidera, la maggior parte dei formati di comunicazione utilizzati nei servizi REST (come JSON) non hanno comunque un modo formale di descriverne i contenuti.

Riassumendo, si potrebbe dire che i webservices SOAP sono solitamente usati per integrare (possibilmente disparate) soluzioni, mentre i servizi REST sono più adatti a fornire comunicazioni tra parti della stessa soluzione.

risposta data 05.08.2014 - 11:41

fonte

1

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

In pratica, il consumo di un WSDL da un'altra lingua o piattaforma di implementazione è stato problematico. Livelli di sicurezza WS- * in cima ancora di più.

La mia esperienza è stata principalmente con .Net, Node, Java e PHP in questo senso, e posso dire che quando hai piattaforme che non devono definire i dettagli di un tipo di bambino, o useranno "Oggetto "come definizione, a dir poco problematica. Oltre a questo, per la maggior parte nessuno comprende veramente tutto SOAP / WS- * basandosi molto sugli strumenti per farlo funzionare. Questo strumento ha un sacco di spese generali, e diversi sistemi operano 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 provare a utilizzare 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 in un lotto come servizio di traduzione, semplicemente perché era abbastanza flessibile da accettare implementazioni sporche come client, e potevo scrivere in modo semplice clienti contro il mio payload adattato che ha funzionato meglio. EX: C # ottiene il testo JSON, che uso JSON.Net per convertire in una rappresentazione oggetto che ho definito effettivamente funzionante quando non ho potuto utilizzare un'importazione WSDL.

In pratica questo succede molto.

risposta data 15.08.2015 - 08:29

fonte

-3

Anche se molte delle risposte qui sono fantastiche, penso che la risposta sia MOLTO più semplice: stai osservando la tecnologia sbagliata per il lavoro.

Se stai cercando di creare un servizio SOAP, dovresti attenersi a WCF. È ancora un framework molto potente, Microsoft lo sta ancora sviluppando attivamente, non ci sono stati annunci per noi di pensare che stia andando da nessuna parte in futuro, ed è stato fatto con questo in mente. L'API Web non sostituisce in alcun modo WCF (sebbene sia probabilmente più alla moda di WCF).

Le API Web facevano parte di WCF, ma sono state spostate esattamente sulla famiglia ASP.NET PERCHÉ non si adattava perfettamente alle altre tecnologie WCF. L'API Web è molto più preoccupata dell'uso di HTTP come protocollo applicativo rispetto a un protocollo di trasferimento. In Web API, i verbi HTTP sono re, in WCF HTTP serve solo per abilitare il protocollo SOAP.

Non incolpare API Web per non dare la possibilità di fare certe cose per cui non è stato creato.

risposta data 27.11.2014 - 02:46

fonte

Leggi altre domande sui tag c# asp.net-mvc web-api

Il modo migliore per i metodi di test unitari che chiamano altri metodi all'interno della stessa classe Qual è la differenza tra specifiche tecniche e documenti di progettazione?

score 23 · Accepted Answer

CREATIVITÀ SOAP, RIPOSO E PERSONE

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

Ad esempio, in SOAP il tuo servizio web che consente ai clienti 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 esempi di messaggi, perché ho visto molti nomi di metodi di servizi web divertenti. Ci sono persone davvero creative là fuori.

D'altro canto, se stai esponendo il tuo sistema sottostante usando web api che rispettano veramente i principi REST, il cliente deve solo sapere di avere una risorsa chiamata Users, perché c'è il 99% di possibilità che tu possa creare un utente in questo modo

POST /Users

E ciò si verifica per ogni operazione che si desidera esporre usando SOAP o un RIP web api.

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

DESCRIVERE UN RIPOSO API WEB

Nel campo di come descrivere un RIP di web api, 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 descrivere REST web apis.

Swagger is a specification and complete framework implementation for describing, producing, consuming, and visualizing RESTful web services.

Uso molto Swagger e lo adoro, principalmente perché UI di Swagger che ti consente di generare un bel live console e documentazione per la tua web API.

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

Se usi API Web ASP.NET, alcuni progetti generano automaticamente la specifica Swagger, come Swagger.NET

GENERAZIONE DEI CLIENTI AD UN RIPOSO API WEB

Poiché i vincoli di REST, come il set limitato di verbi (GET, POST, PUT, DELETE, ecc.) non sono così difficili da generare una libreria client su un web API REST.

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

CONVENTION FOR WEB API REST

Per mantenere le nostre vite come semplici sviluppatori è buona norma definire alcune convenzioni su come si comporterebbe il nostro web api REST, lo sforzo migliore che conosco in questo campo è l'ottimo Apigee - Web Api Design ebook . 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 in apis web REST di grandi dimensioni, come Twitter, Facebook, Linkedin, Google, ecc.