Back to top

SOAP vs REST vs RPC vs GraphQL

Formati supportati, curva di apprendimento, use cases, vantaggi e svantaggi

Le Application Programming Interfaces (API) nascono come un tool di intermediazione tra strumenti differenti e permettere integrazioni tra applicazioni. Al fine di permettere un’integrazione più semplice, le API adottano protocolli specifici e sintassi dettagliate dei vari messaggi al fine della loro corretta comprensione. Nel seguente articolo cercheremo di dare una breve definizione di ogni tipologia ( SOAP, REST, RPC e GraphSQL) confrontando ed andando ad individuare il miglior modo di utilizzo. Contattaci subito e senza impegno per una consulenza per il tuo progetto per le API.

Remote Procedure Call(RPC)

Letteralmente una Remote Procedure Call è un modo per permettere l’esecuzione remota di una funzione in un differente contesto, di fatto estende le local procedure attraverso HTTP API.

Attualmente, l’ultima versione gRPC, sviluppata da Google ed utilizzata da aziende come Netflix e Cisco, supporta un sistema di scambio dei messaggi in JSON, XML, Protobuf, Thrift e Flatbuffers. Inoltre implementa il supporto per load balancing, tracing, health checking e authentication; rendendolo eccellente per i Microservizi.

I vantaggi di RPC:

  • interazione semplice grazie all’utilizzo di GET e POST
  • estensione delle funzioni in maniera immediata grazie all’isolamento degli end-point che rende semplice la creazione ed aggiunta di nuovi
  • elevate performance grazie a payload leggeri e capacità di ottimizzazione della rete.

Gli svantaggi di RPC:

  • eccessivo accoppiamento con il sistema sottostante aumentando i rischi di sicurezza
  • le funzioni non sono “discoverable”, vale a dire che non c’è modo di comprendere cosa una funzione fa a priori
  • la facilità di creare nuove funzioni rende spesso più efficiente creare una nuova piuttosto che modificarne una esistente. ciò si traduce in una enorme lista di funzioni da mantenere.

Use cases di RPC:

  • enterprise messaging per es. ora è utilizzato da Google e Facebook
  • command API per inviare comandi ad un sistema remoto, è l’esempio di Slack
  • microservizi interni che non hanno bisogno di essere pubblici

Simple Objects Access Protocol (SOAP)

SOAP, come indica anche l’acronimo, è un protocollo basato su XML e fortemente standardizzato, che si traduce in una struttura complessa e definita. La logica è scritta in un Web Service Description Language (WSDL) e definisce come l’endpoint lavora. Supporta la comunicazione sia stateless sia stateful ed in quest’ultima modalità lo rende particolarmente idoneo per complesse transazioni tra più attori ( classiche transazioni bancarie).

I vantaggi di SOAP:

  • indipendente dal linguaggio utilizzato e dalla piattaforma
  • flessibile ed adattabile a qualsiasi protocollo per il trasporto
  • gestione dell’errore implementata in maniera nativa
  • estensioni di sicurezza con gestione di privacy, integrità e cifratura

Gli svantaggi di SOAP:

  • supporta esclusivamente XML
  • utilizzo di larga quantità di banda per via dei file XML molto grandi
  • complesso da utilizzare in quanto richiede conoscenze specifiche dei protocolli in uso
  • schema rigido che aumenta gli sforzi lavorativi per metterlo in produzione

Use cases di SOAP:

  • enforcing di contratti software formali tra partner
  • transazioni finanziarie ed economiche
  • elevate sicurezza nella trasmissione di informazioni

Representational state transfer (REST)

REST è uno stile architetturale di API autodefinito e nato per un pubblico esteso di “consumatori” di API. Supporta XML, JSON, HTML e non ultimo anche il plain text. Le API REST hanno un’interfaccia uniforme, sono stateless, supportano il caching ed operano come client-side rendendo indipendente lo sviluppo di entrambe le parti. Fanno uso, al loro massimo livello di maturità, di Hypertext As The Engine of Application State (HATEOS), in pratica includendo link metadata ad ogni risposta. Se non implementi HATEOS di fatto stai usando HTTP RPC.

I vantaggi di REST:

  • migliore astrazione che permette un’evoluzione nel tempo migliore
  • descrizione delle API nativa ( discoverability)
  • caching via HTTP
  • supporto di molti formati che la rende ideale per API disponibili pubblicamente

Gli svantaggi di REST:

  • non esiste un “modo giusto” di implementare REST, ciò le rende dipendenti dallo scenario e quindi semplici in teoria ma difficili nella pratica
  • payload pesante per via dei metadata
  • sono spesso necessarie più API differenti per fornire le informazioni chieste

Use cases di REST:

  • gestione di oggetti e dati per moltissimi utenti e consumer
  • resource-driven app

GraphQL

Come abbiamo indicato nel precedente paragrafo, tra gli svantaggi di REST c’è il fatto che sono necessarie più chiamate API per avere le informazioni necessarie. GraphSQL nasce per superare questo limite. GraphSQL è una sintassi per descrivere un richiesta specifica. In pratica si costruisce uno Schema Definition Language(SDL) ed il server restituisce lo schema richiesto. Oltre alle classiche operazioni CRUD, GraphSQL supporta le “sottoscrizioni” per ricevere notifiche dal server.

I vantaggi di GraphSQL:

  • descrizione delle API grazie agli schemi
  • eccellente per la richiesta di dati
  • nessun versioning grazie all’evoluzione sempre compatibile
  • messaggi di errore dettagliati
  • gestione dei permessi per rendere alcuni dati pubblici altri privati

Gli svantaggi di GraphSQL:

  • possibili problemi di performance che rendono più adatto REST per query complesse
  • complessità del caching
  • ripida curva di apprendimento iniziale

Use cases di GraphSQL:

  • mobile API per caricamento di dati
  • aggregazione di dati provenienti da più sistemi
  • microservizi

Quale API scegliere

Quale scegliere dipende sempre da una serie di fattori come l’ambiente di sviluppo, il contesto, le risorse, la manutenzione necessaria e tantissime altre variabili.

Puoi scegliere di provarle tutte con dei Proof of Concept (PoC) oppure di seguire il tuo istinto rischiando perdite di tempo e di soldi oppure puoi scegliere una nostra consulenza che ti fornisce la soluzione senza assumerti rischi ed inoltre, l’intero costo viene scontato completamente da futuri progetti. Contattaci subito e senza impegno per maggiori informazioni.

Perche Glue Labs

Ti garantiamo sviluppo ed architetture 12 mesi da qualsiasi bug, mettiamo competenza avanzata a supporto dei tuoi progetti ed esperienza in tantissimi settori e con numerosi Clienti per essere aderenti alle tue necessità di business. Contattaci subito e senza impegno per maggiori informazioni.

Casi di Successo

Il leader mondiale in sistemi di controllo di impianti refrigeranti, umidificazione e aereazione presente in 75 paesi usa le nostre soluzioni Web Application e System Integration per selezionare le componenti industriali e fornire documentazione tecnica in ambiente controllato e sicuro.

Inizia ora il tuo progetto

CONTATTI

Scrivici dal form di contatto

Tel +39 06 56549766
Fax +39 06 21122581

Mail: info@glue-labs.com
Pec: gluelabs@legalmail.it

Dove Siamo
Roma: Piazza Don Sturzo 15
Padova: Via Savonarola 217
Milano: Via Lazzaretto 19
Torino: P.zza XVIII Dicembre 5

Nome*

E-mail*

Telefono(per un contatto più rapido)

Come possiamo aiutarti?

Altro che vuoi dirci?

Inviando i tuoi dati accetti le condizioni sulla privacy. Li useremo per rispondere alle tue domande e richieste.

TOP