Jason Murphy, Head Nerd di N-able, ha recentemente incontrato 4 tecnici di MSP conosciuto a livello mondiale con sede in California. Essi hanno posto a Murphy due domande importanti su N-central: 

Dispone delle API richieste per estrarre le informazioni necessarie sugli asset? 

E’ in grado di estrarre il monitoraggio in uno stato non riuscito in modo da utilizzare i dati con il gateaway API di Microsoft Azure? 

Cosa sono  REST e SOAP?

REST (REpresentational State Transfer), è uno stile architettonico, un insieme di principi per la progettazione di applicazioni in rete e API (Application Programming Interface) che utilizzano HTTP (Hypertext Transfer Protocol) per la comunicazione.

SOAP, o Simple Object Access Protocol, è invece una specifica del protocollo che permette lo scambio di informazioni strutturate nei servizi Web. Essa fornisce un metodo di programmazione per la comunicazione in rete di applicazioni e sistemi. Si basa su XML (eXtensible Markup Language) e utilizza, solitamente, HTTP o altri protocolli per l’invio di messaggi tra client e server. 

SOAP è una  tecnologia legacy?

Le API SOAP sono legacy? La risposta è no! Neanche lontanamente. In termini di architettura N-central fa uso di una distribuzione Enterprise Linux con un database PostgreSQL dove l’interfaccia con le API SOAP non è facile come per REST. Per questo molti credono che API SOAP siano obsolete, ma anche qui la risposta è negativa! Vediamo quindi i vantaggi e gli svantaggi di tale tecnologia. 

Vantaggi 

SOAP fornisce un protocollo standardizzato per lo scambio di informazioni strutturate e dispone di meccanismi di gestione degli errori e di tolleranza a quelli  incorporati. Supporta le transazioni ACID (Atomicity, Consistency, Isolation, Durability) e garantisce una consegna affidabile dei messaggi.

Le API SOAP richiedono un contratto formale definito utilizzando Web Services Description Language (WSDL). Questo contratto fornisce una descrizione dettagliata dell’API, comprese le operazioni, i tipi di dati, i formati dei messaggi e i protocolli di trasporto. Il contratto facilita l’integrazione e riduce l’ambiguità tra i diversi sistemi.

SOAP supporta vari standard di sicurezza, come WS-Security, che fornisce sicurezza a livello di messaggio, crittografia e firme digitali.

Le API SOAP sono indipendenti dal linguaggio e possono essere utilizzate con un’ampia gamma di piattaforme e linguaggi di programmazione. L’ampio supporto per diversi protocolli come HTTP, SMTP, TCP/IP e altri consente a SOAP di funzionare in ambienti eterogenei.

SOAP offre funzionalità avanzate come WS-AtomicTransaction per le transazioni distribuite, WS-ReliableMessaging per una consegna affidabile e WS-Policy per la definizione delle policy di servizio. Queste caratteristiche rendono SOAP adatto per applicazioni di livello aziendale con requisiti complessi.

Svantaggi

Le API SOAP tendono ad essere più complesse rispetto ad altre architetture di servizi Web come REST. I messaggi  sono in genere basati su XML e richiedono un sovraccarico aggiuntivo di analisi ed elaborazione. La complessità può rendere quindi più difficile per la comprensione e l’implementazione dei servizi per i professionisti IT.

I messaggi SOAP sono dettagliati e contengono molti metadati, che si aggiungono alle dimensioni del payload. Ciò può comportare dimensioni dei messaggi maggiori e un maggiore utilizzo della larghezza di banda rispetto ad alternative più leggere come REST, specialmente in ambienti con limiti di banda o con un utilizzo API su larga scala.

A causa della natura basata su XML di SOAP, l’elaborazione dei messaggi può essere costosa. Le ulteriori operazioni di analisi, convalida e trasformazione necessarie possono influire sulle prestazioni e sui tempi di risposta delle API basate,  in particolare negli scenari a throughput elevato.

Le API SOAP non sono abbastanza supportate dai browser Web rispetto alle API REST. Basandosi su XML, richiedono funzionalità di analisi più avanzate, che potrebbero non essere completamente supportate o facilmente implementate nelle applicazioni JavaScript lato client.

I messaggi SOAP non sono progettati per essere facilmente leggibili o comprensibili dagli esseri umani. La struttura ei metadati basati su XML rende, infatti, più complicata l’ispezione manuale o il debug dei messaggi, rendendo la risoluzione dei problemi più impegnativa.

Vantaggi delle  API REST

  1. Semplicità e facilità d’uso: le API REST sono più semplici e facili da comprendere e implementare rispetto alle API SOAP. REST sfrutta metodi HTTP standard come GET, POST, PUT e DELETE, che sono facilmente compresi e supportati.
  2. Comunicazione: le API REST in genere utilizzano formati di dati leggeri come JSON (JavaScript Object Notation) per la rappresentazione dei dati, che si traduce in dimensioni dei messaggi più piccole e un trasferimento dei dati più efficiente. Ciò rende le API REST più veloci e più adatte per ambienti con limiti di larghezza di banda o applicazioni mobili.
  3. Scalabilità e prestazioni: la natura stateless delle API REST consente il ridimensionamento orizzontale e prestazioni migliori in presenza di carichi pesanti. L’assenza di gestione delle sessioni lato server rende le rende inoltre più scalabili, in quanto non si basano sull’archiviazione dello stato del client. Questa scalabilità garantisce una migliore reattività e un’elaborazione più rapida.
  4. Flessibilità e compatibilità: le API REST sono flessibili e possono essere utilizzate da un’ampia gamma di client, inclusi browser Web, dispositivi mobili e altri sistemi. Non sono legati a uno specifico stack tecnologico o linguaggio di programmazione, consentendo l’interoperabilità tra diverse piattaforme. La compatibilità con l’infrastruttura e gli standard web esistenti, infine, semplifica l’integrazione con altri servizi web.
  5. Cacheability e caching: le API REST sfruttano i meccanismi di caching del protocollo HTTP, consentendo la memorizzazione nella cache delle risposte da parte di client o sistemi intermedi. La memorizzazione migliorerà significativamente le prestazioni riducendo la necessità di richieste ridondanti al server.

Qual è la soluzione giusta  per te?

Precedentemente le  API SOAP venivano utilizzate in aziende in cui i contratti formali, la sicurezza e l’affidabilità erano fondamentali, ma la crescente popolarità di alternative più leggere e semplici come REST ha portato ad una minore adozione delle prime in molti scenari di sviluppo Web moderni. Ci sono però anche alcuni svantaggi per l’API REST, soprattutto perché esse spesso possono portare a un recupero eccessivo o insufficiente dei dati, causando un controllo granulare sul recupero e la manipolazione dei dati, che talvolta si limita alle architetture RESTful.

In definitiva, la scelta tra SOAP e REST dipende da fattori quali i requisiti specifici dell’applicazione, l’infrastruttura esistente e il livello di formalità e complessità necessario nella comunicazione API. Ma cosa più importante, la differenza sta nell’utilizzo d N-central.

In genere, i tecnici RMM e gli utenti finali, infatti, non sono sviluppatori web aziendali esperti, ma admin di sistema o tecnici:

 

E’ per questo che cresce la domanda per convertire N-central in API REST.

Compila il form per avere maggiori informazioni su N-able N-central

Articolo originale: SOAP vs REST – Wichi is Best for Integrating with N-central? – Autore: Brian JBest

Credits Articolo

Credits Articolo

Scritto e riadattato da CIPS Informatica per N-able 

© 2022 N‑able Solutions ULC and N‑able Technologies Ltd. All rights reserved.

This document is provided for informational purposes only and should not be relied upon as legal advice. N‑able makes no warranty, express or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information contained herein.

The N-ABLE, N-CENTRAL, and other N‑able trademarks and logos are the exclusive property of N‑able Solutions ULC and N‑able Technologies Ltd. and may be common law marks, are registered, or are pending registration with the U.S. Patent and Trademark Office and with other countries. All other trademarks mentioned herein are used for identification purposes only and are trademarks (and may be registered trademarks) of their respective companies.

Torna in cima