Vuoi collegare la tua app a Facebook in modo che possa generare post automaticamente o a Instagram in modo da poter ripubblicare le foto con determinati hashtag?
Potresti anche voler includere i video di YouTube sul tuo sito web. Le interfacce di programmazione delle applicazioni consentono di eseguire tutte queste attività e altre (API).
Diverse applicazioni possono "parlare" tra loro in modo sicuro e standardizzato grazie ad API come l'API di Instagram, l'API di Facebook e l'API di YouTube.
In altre parole, un programma può prendere funzionalità o dati da un altro software e utilizzarli per migliorare le proprie funzionalità o l'esperienza utente. Ma in che modo le app possono fare queste richieste, elaborarle e rispondervi in un modo che gli altri possano capire?
Dipende da come è stata creata l'API. Quando si parla di progetti API (Application Programming Interface), è normale confrontare SOAP e REST, due dei paradigmi API più importanti.
Non appena le API SOAP (Simple Object Access Protocol) sono diventate il gold standard per aziende come Oracle, Sun e PayPal, c'è stata una risposta uguale e contraria circa un anno dopo verso le API REST di Google, Amazon ed eBay.
In questo post, confronteremo e confronteremo le API SOAP con le API REST in modo che tu possa decidere quale è la migliore per i tuoi scopi.
Inizieremo definendo l'API.
Cos'è l'API?
L'interfaccia di programmazione dell'applicazione è denominata API. Le API sono essenzialmente una raccolta di metodi e funzioni che consentono lo sviluppo di app. Hanno accesso alle informazioni e alle funzioni di diversi programmi, servizi o sistemi operativi.
Servono come una sorta di intermediario tra i vari sistemi software. Consentono di "parlare" tra due programmi non collegati.
Prendiamo l'esempio di un agente di cambio che è attivamente coinvolto nel trading e nei mercati finanziari. Una raccolta di automatizzati algoritmi di trading può essere collegato alla piattaforma di broker di trading preferita dal trader tramite un'API. Ciò consente a te, commerciante, di eseguire transazioni elettroniche o visualizzare quotazioni e dati sui prezzi in tempo reale.
Cos'è il RIPOSO?
Le vere API dei "servizi web" includono REST (Representational State Transfer). Le API REST sono basate su URI (Uniform Resource Identifiers, di cui un URL è un tipo speciale), il protocollo HTTP e il formato di dati JSON incredibilmente compatibile con i browser.
Potrebbe essere eventualmente utilizzato anche il protocollo SOAP, come abbiamo già detto. Le API REST possono essere facili da creare e far crescere, ma possono anche essere enormi e difficili: tutto dipende da come vengono create, ampliate e da cosa sono destinate a fare.
Vincoli di risorse, requisiti di sicurezza ridotti, compatibilità client browser, rilevabilità, integrità dei dati e scalabilità sono alcuni dei motivi per cui vorresti sviluppare un'API per essere RESTful, cose che si applicano effettivamente ai servizi Web.
REST offre un'opzione più leggera. SOAP era difficile da usare e gravoso per molti sviluppatori. Ad esempio, l'utilizzo di SOAP con JavaScript richiede la scrittura di molto codice per completare operazioni semplici poiché la struttura XML necessaria deve essere creata ogni volta.
REST (in genere) utilizza un URL semplice al posto di una richiesta XML. Sebbene ci siano rare circostanze in cui è necessario fornire maggiori dettagli, la maggior parte dei servizi Web RESTful utilizza solo la tecnica dell'URL.
I quattro verbi HTTP 1.1 GET, POST, PUT e DELETE possono essere utilizzati da REST per eseguire operazioni. A differenza di SOAP, REST non ha bisogno che la risposta sia in XML.
Sono disponibili servizi Web basati su REST che generano dati nei formati Command Separated Value (CSV), JavaScript Object Notation (JSON) e Really Simple Syndication (RSS).
L'obiettivo è che tu possa ottenere i risultati di cui hai bisogno in un formato facile da analizzare all'interno della lingua che stai utilizzando per la tua applicazione.
Caratteristiche
- REST sottolinea soprattutto la semplicità, grazie ai protocolli HTTP.
- Il web è più adatto per REST. È compatibile con i browser perché JSON viene utilizzato come formato dei dati.
- REST è rinomato per la sua eccezionale scalabilità e velocità.
- Le connessioni e le architetture client-server sono rese più accessibili dalle API REST. Se è RESTful, viene costruito utilizzando questo modello client-server, con viaggi di andata e ritorno tra le due parti che passano i payload dei dati.
- Le API REST utilizzano un'interfaccia standard solitaria. Garantire che tutte le app si connettano in modo uniforme e attraverso lo stesso gateway, semplifica il modo in cui le applicazioni comunicano con l'API.
Cos'è il SAPONE?
Il suo protocollo, chiamato SOAP (Simple Object Access Protocol), è un po' più complicato del REST poiché specifica più standard, inclusi quelli relativi alla sicurezza e alla consegna dei messaggi.
Queste norme intrinseche comportano un po' di sovraccarico. Tuttavia, possono essere un fattore decisivo per le aziende che necessitano di funzionalità più estese di sicurezza, transazione e conformità ACID (Atomicity, Consistency, Isolation, Durability).
Ai fini di questo confronto, è importante notare che molti dei vantaggi di SOAP spesso non si applicano alle applicazioni dei servizi Web, il che le rende più adatte a scenari di tipo aziendale.
Livelli di sicurezza più elevati (come quando a Mobile App interagisce con una banca), le app di messaggistica che richiedono una comunicazione affidabile, l'interazione con i sistemi legacy o la conformità ACID sono alcuni dei motivi per cui vorresti progettare un'applicazione utilizzando un'API SOAP.
Le funzionalità di messaggistica offerte da SOAP sono interamente basate su XML. Le vecchie tecnologie incompatibili con Internet come il Distributed Component Object Model (DCOM) e Common Object Request Broker Architecture sono state sostituite da SOAP quando è stato creato per la prima volta da Microsoft (CORBA).
La dipendenza dalle comunicazioni binarie causa il fallimento di questi sistemi. Su Internet, la messaggistica XML come quella usata da SOAP funziona meglio.
Caratteristiche
- La sicurezza di SOAP è notevolmente più stretta. WS-Security è uno standard integrato che offre funzionalità di sicurezza SOAP aggiuntive a livello aziendale, se necessario, oltre al supporto SSL.
- Ragionamento riuscito/riprova per prestazioni di messaggistica affidabili. Poiché REST non dispone di un meccanismo di messaggistica standardizzato, può riprovare solo quando la comunicazione non riesce. Anche quando si utilizzano gli intermedi SOAP, SOAP offre affidabilità end-to-end grazie alla sua logica di successo/riprova incorporata.
- SOAP è già conforme agli standard ACID. Determinando come le transazioni possono interagire con il database, la conformità ACID riduce al minimo le anomalie e salvaguarda la coerenza di un database. Poiché ACID è più prudente rispetto ad altri modelli di coerenza dei dati, viene spesso utilizzato nella gestione di transazioni sensibili, finanziarie o di altro tipo.
- È semplice da comprendere per i programmatori poiché SOAP è una comunicazione totalmente basata su XML.
- Il protocollo di messaggistica XML è un'aggiunta al protocollo HTTP.
- Le comunicazioni da un computer a un altro computer possono essere diffuse tramite messaggistica SOAP.
- Può essere implementata anche l'architettura client-server. Un messaggio di protocollo SOAP può essere utilizzato dal client per chiamare una chiamata di procedura remota situata lato server.
REST vs SOAP Differenze
1. architettura
Un'API ha lo scopo di mostrare principalmente componenti specifici della logica aziendale di un'applicazione su un server. Mentre REST utilizza gli URI per lo stesso scopo, SOAP utilizza un'interfaccia di servizio per questo.
Le API REST vengono create in base ai dati, mentre le API SOAP vengono sviluppate in base alle funzionalità illustrate dall'API. Rispetto a SOAP, che è più basato sulle funzioni, REST è un design più basato sui dati.
2. caching
I dati contrassegnati come memorizzabili nella cache possono essere nuovamente utilizzati dai browser senza richiedere loro di effettuare una nuova richiesta al server. Risparmiare tempo e fatica ne è un vantaggio.
Le risposte non verranno memorizzate nella cache a livello HTTP poiché le query SOAP vengono inviate tramite richieste POST, che lo standard HTTP ritiene non idempotente. Se desideri utilizzare la memorizzazione nella cache, devi comunque creare le tecniche necessarie poiché le API REST non includono questa implementazione.
3. Risorse e larghezza di banda
A causa del trasferimento del carico utile in stile busta utilizzato da SOAP, si verifica un modesto aumento dell'overhead, che richiede larghezza di banda aggiuntiva. La natura leggera di REST è un vantaggio in queste situazioni perché è generalmente utilizzata per i servizi Web.
4. Sicurezza
È auspicabile la sicurezza WS, che supporta SOAP ed è leggermente più completa di SSL a livello di trasporto. Anche l'integrazione di misure di sicurezza a livello aziendale è una soluzione perfetta.
La crittografia end-to-end tramite SSL è supportata sia da SOAP che da REST e REST può utilizzare HTTPS, la variante sicura del protocollo HTTP.
5. Gestione dei carichi utili
I dati trasmessi attraverso Internet sono indicati come payload. Un carico utile considerato "pesante" necessita di risorse aggiuntive. Rispetto a SOAP, che utilizza XML, REST usa spesso JSON e HTTP per ridurre il carico utile.
Una libreria Client specializzata con codice generato deve in genere essere utilizzata dal Cliente per accedere alle API SOAP a causa del loro contratto di comunicazione estremamente rigoroso.
Di conseguenza, SOAP offre un livello di astrazione inferiore rispetto a REST ed è più strettamente connesso al server.
Quando usare REST?
- Creazione di API pubbliche: le API REST sono preferite per la creazione di servizi Web pubblici perché sono considerate più semplici da usare e adottare rispetto alle API SOAP. Inoltre, SOAP offre diverse misure di sicurezza integrate che REST non ha, sebbene queste caratteristiche non siano richieste quando si lavora con dati e servizi aperti.
- Realizzazione di app mobili: REST è perfetto per la creazione di applicazioni mobili poiché è piccolo, efficace, senza stato e memorizzabile nella cache.
- Utilizzo di risorse server e larghezza di banda scarse: tutte le richieste a un'API REST devono essere stateless, il che significa che ogni interazione è separata e ogni richiesta e risposta contiene tutti i dati necessari per completare l'interazione. Il server non salva i record delle richieste precedenti poiché tratta ciascuna come una nuova richiesta. Di conseguenza, il server richiede molta meno memoria e funziona più rapidamente perché una richiesta non richiede ulteriori azioni o il recupero di dati storici.
Quando usare il SAPONE?
- Creazione di API private, in particolare per le grandi aziende: SOAP è perfetto per le applicazioni aziendali poiché consente il flusso di dati in un ambiente decentralizzato e distribuito e contiene diverse funzionalità di sicurezza online.
- Utilizzo di un protocollo di trasporto diverso da HTTP come livello sottostante: SOAP non dipende da HTTP come livello sottostante. A seconda dell'applicazione, è possibile utilizzare SMTP (Simple Mail Transfer Protocol), JMS (Java Messaging Service) o un altro protocollo di trasporto.
- Lavorare con operazioni con stato: a differenza delle richieste alle API REST, le richieste alle API SOAP sono stateful, il che significa che il server salva le informazioni sul client e le utilizza attraverso una catena di richieste o operazioni. Anche se utilizza più larghezza di banda e risorse del server, è fondamentale per eseguire azioni di routine o collegate, come i bonifici bancari.
Conclusione
Il confronto tra le API REST e SOAP rende abbastanza evidente che REST è preferibile a SOAP. Tuttavia, ci sono situazioni in cui è richiesta l'API SOAP. In alcuni casi, i servizi Web vengono creati combinando API REST e SOAP.
Pertanto, il caso d'uso determinerà quale stile API funzionerà meglio.
Lascia un Commento