Differenza tra Endpoint, Servizio web, REST, API e Proxy

Endpoint

In ambito reti e comunicazioni il termine endpoint fa riferimento ad un dispositivo o servizio, anche denominato nodo, che accetta ed invia comunicazioni attraverso la rete LAN o WAN a cui è connesso. Quindi in pratica si utilizza questo termine per riferirsi al punto di connessione in cui sono esposte le risorse servite da un determinato web server in esecuzione su una macchina. L’endpoint di un servizio fornisce dunque le informazioni necessarie ad un client per raggiungere le risorse.

Servizio web

Un servizio web è un qualsiasi software che si rende disponibile su Internet e utilizza un sistema di messaggistica XML standardizzato. XML viene utilizzato per codificare tutte le comunicazioni a un servizio Web. Ad esempio, un client richiama un servizio Web inviando un messaggio XML, quindi attende una risposta XML corrispondente. Poiché tutta la comunicazione è in XML, i servizi web non sono legati a nessun sistema operativo o linguaggio di programmazione: Java può parlare con Perl; Le applicazioni Windows possono dialogare con le applicazioni Unix. In altre parole, i servizi Web sono applicazioni autonome, modulari, distribuite e dinamiche che possono essere descritte, pubblicate, localizzate o invocate sulla rete per creare prodotti, processi e catene di fornitura. Queste applicazioni possono essere locali, distribuite o basate sul Web. I servizi Web si basano su standard aperti come TCP / IP, HTTP, Java, HTML e XML.
Infine, i servizi Web sono utilizzati come sistemi di scambio di informazioni basati su XML che utilizzano Internet per l’interazione diretta applicazione-applicazione. Questi sistemi possono includere programmi, oggetti, messaggi o documenti.

Riassumendo, un servizio web completo è, quindi, qualsiasi servizio che:

1. È disponibile su Internet o reti private (intranet)
2. Utilizza un sistema di messaggistica XML standardizzato
3. Non è legato a nessun sistema operativo o linguaggio di programmazione
4. Si autodefinisce tramite una grammatica XML comune
5. È rilevabile tramite un semplice meccanismo di ricerca.

REST – Representational State Transfer

REST definisce un insieme di principi architetturali per la progettazione di servizi web, permettendo di creare sistemi distribuiti facilmente scalabili e riutilizzabili. Esso descrive uno stile architetturale con delle linee guida, non rappresenta un sistema concreto e nemmeno uno standard, ma dei concetti che delineano l’organizzazione fondamentale di un sistema: le relazioni tra i componenti e con l’ambiente e le regole che ne governano la progettazione e l’evoluzione.

Le regole dello stile architetturale REST riducono i modi in cui il server può processare e rispondere alle richieste del client e sono tali per cui, se rispettate, conferiscono al sistema proprietà non funzionali come miglioramento di performance, scalabilità (proprietà di un sistema di gestire un numero crescente di lavoro aggiungendovi risorse), semplicità, modificabilità, visibilità, portabilità e affidabilità.

A partire dagli anni 2000, quando è stato introdotto nella tesi di dottorato di Roy Thomas Fielding, l’approccio REST è stato ampiamente adottato dagli sviluppatori per la realizzazione di servizi web. Questo perché il web ha tutte le caratteristiche necessarie per essere considerato una piattaforma di elaborazione distribuita secondo i principi REST, senza la necessità di altre sovrastrutture, bastano infatti i suoi concetti basilari:

1. URI, meccanismo per individuare risorse in una rete;
2. HTTP, protocollo per richiedere una risorsa ad una macchina;
3. un linguaggio per la rappresentazione dei contenuti, come ad esempio HTML, XML o JSON.

Questa visione si contrappone all’approccio dei servizi web basati su SOAP2 che è un protocollo per lo scambio di dati strutturati basato sul concetto di chiamata remota.

I principi che rendono un sistema RESTful sono i seguenti:

1. Il concetto fondamentale sul quale si basa un servizio web RESTful è l’esistenza delle risorse. Per risorsa si intende un qualsiasi elemento oggetto di elaborazione e fonte di informazioni come ad esempio un libro, un articolo, un file o un qualsiasi oggetto su cui è possibile effettuare operazioni. Ciascuna risorsa deve essere identificata univocamente, ed essendo in ambito web, il meccanismo più naturale per individuare una risorsa è dato dall’URI. Nell’applicazione realizzata un esempio di URI è <endpoint>/primers/18, che identifica un set di primer caricato nel sistema. Le risorse sono concettualmente separate dalla loro rappresentazione che viene restituita al client, questa infatti solitamente consiste in un formato non coincidente con la risorsa interna al server.
2. Architettura client-server: client e server hanno compiti diversi e sono connessi tramite un insieme di interfacce. Separare i ruoli dell’interfaccia utente da quelli dello spazio di archiviazione migliora la portabilità in piattaforme diverse, dal momento che il client non deve salvare le informazioni condivise dal server, e la scalabilità, semplificando le componenti server che non devono occuparsi dell’interfaccia grafica o dello stato del client. La conseguenza vantaggiosa è che server e client possono essere sostituiti e sviluppati indipendentemente fintantoché l’interfaccia non viene modificata.
3. Comunicazione senza stato (stateless): stabilisce che il server non memorizza dati di sessione client e implica che ciascuna richiesta non deve avere alcuna relazione con le richieste precedenti e successive. Ciò non significa che le applicazioni non possono avere uno stato, ma che il server registra e gestisce solo lo stato delle risorse da lui esposte; nel caso sia necessaria la presenza di dati specifici della sessione, questi devono essere conservati e gestiti dal client e, se necessario, trasferiti al server in ogni richiesta. La principale ragione di tale scelta è la scalabilità: un livello di servizio che non deve mantenere sessioni client è molto più semplice da ridimensionare, mantenere lo stato di una sessione ha infatti un costo in termini di risorse lato server e all’aumentare del numero di client tale costo può diventare insostenibile. Inoltre, con una comunicazione senza stato un client può ricevere risposta da un cluster di server, dal momento che questi non hanno vincoli sulla sessione corrente, ottimizzando le prestazioni globali dell’applicazione.
4. Cacheability: le risposte del server devono definire, implicitamente o esplicitamente, se il client può salvarle nella memoria cache, in modo da essere recuperate e usate successivamente, evitando di dover fare una nuova richiesta al server. Se gestito correttamente lo sfruttamento della cache migliora scalabilità e performance, diminuendo il numero di comunicazioni tra client e server, e assicurando che il client usi sempre dati validi e aggiornati.
5. Stratificazione del sistema: principio per cui il client non sa se è connesso e sta comunicando direttamente ad un server di livello più basso o a uno di livello intermedio. Questo comporta che la presenza di un proxy o un bilanciatore di carico tra il client e il server non influisca sulla loro capacità di comunicare e non sia necessario aggiornare il loro codice, ma anzi la loro migliori la scalabilità del sistema, con bilanciamento del carico di richieste tra i server o con cache distribuite. La stratificazione permette a un server di chiamare ulteriori altri server per generare la risposta ad un client. Il principio dà anche la possibilità di migliorare la sicurezza del sistema, permettendo di aggiungerla come strato superficiale e separato da quello di lavoro.
6. Uniformità dell’interfaccia: semplifica e scompone in pezzi l’architettura, permettendo a ogni parte di svilupparsi in modo indipendente. Se il client è in possesso di un URI che punta ad un servizio, conosce di conseguenza anche quali metodi sono disponibili su quella risorsa. Grazie al protocollo HTTP infatti la risposta del server contiene sufficienti informazioni con le quali il client può individuare il metodo da chiamare per estrarre i dati, modificare o eliminare la risorsa nel server in cui questa è salvata.

API – Application Programming Interface

Un’API è un protocollo di comunicazione tra un client e un server che definisce le modalità di realizzazione e integrazione degli applicativi in modo tale che possano comunicare tra loro senza sapere i dettagli specifici dell’implementazione. Le API semplificano sviluppo e utilizzo, offrendo flessibilità e opportunità di innovazione. Solitamente i software espongono un’interfaccia con un set di funzioni che permettono di condividere i dati con i clienti o utenti esterni mantenendo alti i livelli di sicurezza e di controllo delle risorse, inoltre facilitano lo sviluppo di app nativamente cloud.
In ambito web è possibile e molto diffuso lo sviluppo di interfacce alle quali è possibile accedere tramite il protocollo HTTP, queste vengono chiamate API web.

Proxy e reverse proxy

Con proxy si indica un tipo di server web con la funzione di intermediario tra un client e un server che espone risorse. Nell’ambito dei sistemi distribuiti, l’utilizzo di un tale apparato permette di aumentare sicurezza e isolamento ai vari strati software.
I proxy offrono principalmente di tre tipologie di servizio: garantire l’anonimato nella navigazione web, esporre una cache per risorse HTTP, fungere da firewall.
I reverse proxy hanno la funzione specifica di recuperare risorse da uno specifico server web e di riportarle al client che le ha richieste. Spesso i proxy di questo tipo sono utilizzati per proteggere le applicazioni e i framework, o per bilanciare il carico tra più server.