Sto creando un software per il B2B che si rivolge a tutti i tipi di aziende di grandi dimensioni. Si integrerà con i software esistenti delle aziende (sistemi CRM ed ERP). Voglio esporre la mia API tramite REST. Tuttavia, mi chiedo che ho bisogno di servizi web SOAP anche perché non può essere utilizzato dalle aziende?
Voglio dire com'è ora l'ecosistema se dici ai tuoi clienti che non puoi interagire con il mio sistema tramite SOAP?
Se dovrebbe fornire un'API per altri prodotti esistenti con cui interagire, la scelta dovrebbe essere basata sui requisiti di tali prodotti. Commenti di TZHX spiega tutto ciò in dettaglio.
Suppongo, tuttavia, che non sia la tua situazione. In altre parole, i sistemi CRM ed ERP non interagiscono con il tuo software: invece, il tuo prodotto interagisce con quei sistemi CRM ed ERP tramite l'API loro esporre. La tua intenzione è semplicemente di avere un'API per i prodotti futuri che potrebbero essere creati attorno al tuo prodotto e la tua domanda riguarda l'API quella .
In questo caso, la risposta è piuttosto semplice. Fondamentalmente, la popolarità di SOAP è in diminuzione , mentre REST appare molto interessante. A parte l'hype REST, ci sono ragioni concrete che spiegano che: SOAP ha una maggiore larghezza di banda, specialmente rispetto a REST basato su JSON, e SOAP ha una sua nicchia, che si sta restringendo nel tempo. Ad esempio, nel mondo di Microsoft, SOAP tramite WCF è un'opzione interessante; tuttavia, il futuro di WCF è piuttosto sfavorevole .
Fornire SOAP può avere senso in alcune situazioni:
Il tuo prodotto si trova in un campo in cui tutti utilizza SOAP su base giornaliera. Se tutti i tuoi concorrenti forniscono un'API SOAP, puoi averne uno anche.
Il tuo prodotto è indirizzato agli sviluppatori che hanno utilizzato SOAP in passato e non conoscono né si preoccupano di REST.
Gli sviluppatori che interagiranno con il tuo prodotto hanno alcuni potenti strumenti che rendono facile l'utilizzo di SOAP. Ad esempio, nei progetti WCF, qualsiasi servizio che si presenta tramite WSDL può essere importato in Visual Studio e il suo codice sorgente del client verrà generato automaticamente. E aggiornato automaticamente anche quando il servizio cambia. Molto comodo.
In altri casi, l'API REST è in gran parte sufficiente. Tieni presente che puoi sviluppare sia l'API che i client API nelle lingue tradizionali, rendendo più semplice per gli altri sviluppatori interagire con la tua API. Ad esempio, Amazon lo fa, e così fa Google e Twilio e altri.
Nota che le tecnologie e gli ecosistemi sono molto importanti. Ad esempio, il consumo di un servizio SOAP da JavaScript non sarà particolarmente semplice. D'altro canto, se si desidera fornire un servizio .NET utilizzato da un'applicazione .NET, SOAP fornisce l'alternativa più veloce, la maggior parte del codice generato per l'utente.
Leggi altre domande sui tag development-process api-design