Qual era lo scopo di creare l'API REST?

Le API sono usate per comunicare i due diversi flussi (framework). Il meccanismo di SOAP e REST sono usati per creare le API.

SOAP (Simple Object Access Protocol) e REST (Representational State Transfer) sono entrambi protocolli di comunicazione di servizi web. SOAP è stato a lungo l'approccio standard alle interfacce dei servizi web, anche se è stato dominato da REST negli ultimi anni, con REST che ora rappresenta più del 70% delle API pubbliche secondo Stormpath. Comprendete le differenze principali tra SOAP e REST e come ciascuno di essi può beneficiare gli obiettivi della vostra organizzazione.

SOAP VS REST

REST opera attraverso un'interfaccia solitaria e coerente per accedere a risorse denominate. È più comunemente usato quando si espone un'API pubblica su Internet. SOAP, d'altra parte, espone componenti della logica dell'applicazione come servizi piuttosto che dati. Inoltre, opera attraverso diverse interfacce. Per dirla semplicemente, REST accede ai dati mentre SOAP esegue operazioni attraverso un insieme più standardizzato di modelli di messaggistica. Tuttavia, nella maggior parte dei casi, sia REST che SOAP potrebbero essere usati per ottenere lo stesso risultato (ed entrambi sono infinitamente scalabili), con alcune differenze nel modo in cui lo si configura.

SOAP è stato originariamente creato da Microsoft, ed è stato in giro molto più a lungo di REST. Questo gli dà il vantaggio di essere un protocollo consolidato, legacy. Ma anche REST è in giro da un bel po' di tempo. Inoltre, è entrato in scena come un modo per accedere ai servizi web in un modo molto più semplice di quanto sia possibile con SOAP usando HTTP.

Benefici di REST su SOAP

Oltre ad usare HTTP per la semplicità, REST offre una serie di altri vantaggi su SOAP:

• REST permette una maggiore varietà di formati di dati, mentre SOAP permette solo XML.
• Associato a JSON (che tipicamente funziona meglio con i dati e offre un parsing più veloce), REST è generalmente considerato più facile da lavorare.
• Grazie a JSON, REST offre un miglior supporto per i client dei browser.
• REST fornisce prestazioni superiori, in particolare attraverso il caching per le informazioni che non sono alterate e non sono dinamiche.
• E' il protocollo usato più spesso per i principali servizi come Yahoo, Ebay, Amazon, e anche Google.
• REST è generalmente più veloce e usa meno banda. È anche più facile da integrare con i siti web esistenti, senza bisogno di rifare l'infrastruttura del sito. Questo permette agli sviluppatori di lavorare più velocemente piuttosto che spendere tempo a riscrivere un sito da zero. Invece, possono semplicemente aggiungere funzionalità aggiuntive.

Ancora, SOAP rimane il protocollo preferito per alcuni casi d'uso. Il consenso generale tra gli esperti in questi giorni è che REST è il protocollo tipicamente preferito a meno che non ci sia una ragione convincente per usare SOAP (e ci sono alcuni casi in cui SOAP è preferito).

Benefici di SOAP su REST

Perché è possibile ottenere la maggior parte dei risultati usando entrambi i protocolli, a volte è una questione di preferenze personali. Tuttavia, ci sono alcuni casi d'uso per i quali SOAP tende ad essere più adatto. Per esempio, se avete bisogno di una sicurezza più robusta, il supporto di SOAP per WS-Security può essere utile. Offre alcune garanzie aggiuntive per la privacy e l'integrità dei dati. Fornisce anche il supporto per la verifica dell'identità attraverso intermediari piuttosto che solo da punto a punto, come fornito da SSL (che è supportato sia da SOAP che da REST).

Un altro vantaggio di SOAP è che offre una logica di riprova integrata per compensare le comunicazioni fallite. REST, d'altra parte, non ha un sistema di messaggistica integrato. Se una comunicazione fallisce, il client deve occuparsene riprovando. Non c'è anche un insieme standard di regole per REST. Questo significa che entrambe le parti (il servizio e il consumatore) devono capire sia il contenuto che il contesto.

Altri benefici di SOAP includono:

• Il protocollo HTTP standard di SOAP rende più facile operare attraverso firewall e proxy senza modifiche al protocollo SOAP stesso. Ma, poiché usa il complesso formato XML, tende ad essere più lento rispetto a middleware come ICE e COBRA.
• Inoltre, mentre è raramente necessario, alcuni casi d'uso richiedono una maggiore affidabilità transazionale di quella che può essere raggiunta con HTTP (che limita REST in questa capacità). Se avete bisogno di transazioni ACID-compliant, SOAP è la strada da percorrere.
• In alcuni casi, progettare servizi SOAP può effettivamente essere meno complesso rispetto a REST. Per i servizi web che supportano operazioni complesse, che richiedono il mantenimento del contenuto e del contesto, progettare un servizio SOAP richiede meno codifica nel livello dell'applicazione per le transazioni, la sicurezza, la fiducia e altri elementi.
• SOAP è altamente estensibile attraverso altri protocolli e tecnologie. Oltre a WS-Security, SOAP supporta WS-Addressing, WS-Coordination, WS-ReliableMessaging, e una serie di altri standard di servizi web, una lista completa dei quali si può trovare su W3C.

Alla fine della giornata, il miglior protocollo è quello che ha più senso per l'organizzazione, i tipi di clienti che è necessario supportare, e ciò di cui si ha bisogno in termini di flessibilità. La maggior parte delle nuove API sono costruite usando REST e JSON, semplicemente perché in genere consuma meno banda ed è più facile da capire sia per gli sviluppatori che implementano le API iniziali sia per gli altri sviluppatori che possono scrivere altri servizi contro di esse. Poiché è più facilmente consumato dalla maggior parte dei browser web di oggi, REST+JSON è diventato la tecnologia di defacto per la maggior parte delle API pubbliche. Tuttavia, SOAP rimane un protocollo prezioso in alcune circostanze. Inoltre, non bisogna guardare lontano per trovare fan sfegatati che sostengono SOAP per certi casi d'uso.

fonte da : stackify.com