Android vs iOS

Android (2005)
●​ Open Source​
●​ Librerie sia native che composte (usano le native)​

●​ API Level = versione di Android​

●​ Linguaggi: Java, Groovy​
iOS
●​ Non Open Source​
●​ Usa librerie composte​
●​ Concetti simili:​
○​ Trusted Execution Environment​

Activity e Componenti
●​ Activity: componente grafica, interagisce con l’utente​
●​ Service: esecuzione in background​
●​ Broadcast Receiver: riceve eventi di sistema (es. batteria scarica)​
●​ Content Provider: canale di comunicazione tra app diverse​
●​ Intent: permette di attivare Activity e passare dati​

Ciclo di vita di un’Activity

●​ Ogni Activity ha un ciclo di vita gestito da funzioni che si possono sovrascrivere.​
●​ Esempio:​
○​ onCreate() → eseguita quando parte l’app
 ​

Note Storiche
●​ Android nasce nel 2003 a Mountain View​
●​ Acquistato da Google nel 2005 → lo rende open source​
●​ Android 26 = Oreo (API Level 26)​

Altre Note
●​ API Level indica la versione Android; versioni successive non garantiscono compatibilità con quelle precedenti​
●​ Widget: gruppo grafico per info e operazioni rapide (es. meteo, orologio)​

Modalità di programmazione
App Native
●​ Sviluppate per un sistema operativo specifico (es. Android, iOS)​
●​ Funzionano solo su quel sistema e sfruttano tutte le funzionalità del dispositivo​
App Web
●​ Sviluppate con strumenti web (HTML, JavaScript, CSS)​
●​ Accessibili via browser​
●​ Non sfruttano al massimo le funzionalità hardware​
App Ibride (Cross-Platform)
●​ Sviluppate con IDE che permettono di creare app per diversi sistemi operativi​

APK
●​ È il pacchetto generato da Android Studio da installare sul dispositivo​
MANIFEST (file .xml)
●​ Descrive le caratteristiche dell'app​
●​ Viene generato nel progetto Android e letto da ART​

Sistemi distribuiti
Sistema Centralizzato
●​ I dati e l’elaborazione sono su una sola macchina​
●​ Esempio: Word​
Sistema Distribuito
●​ I dati sono memorizzati su più macchine​
●​ L’elaborazione avviene su più macchine​
●​ Esempio: Google Docs​
●​ Insieme di applicazioni indipendenti che collaborano per uno scopo comune​
●​ Usano una rete come infrastruttura software​

Concorrente vs Distribuito
●​ Concorrente: un processo utilizza sottoprocessi per suddividere il lavoro​
 ●​ Distribuito: i processi sono su macchine diverse​

Definizioni importanti
●​ Leslie Lamport: un sistema distribuito è tale che, anche se una macchina ha un errore, gli altri computer non se ne
accorgono​
●​ Andrew Tanenbaum: un sistema distribuito è una collezione di macchine indipendenti che l’utente percepisce come
un’unica applicazione​

Esempi
●​ App social su cellulare → esempio di sistema distribuito​

Ricerca
●​ Es. Google si suddivide in diverse fasi:​
○​ Web crawling: macchine che scansionano e raccolgono pagine​
○​ Parsing e indicizzazione: analisi dei contenuti e creazione degli indici​
○​ Query: interpretano l’espressione cercata, valutano gli indici e preparano la risposta​
○​ Output: predisposizione della pagina di risposta​
DNS (Domain Name System)
●​ Sistema usato per la conversione tra nomi di dominio e indirizzi IP​
●​ Costituito da tabelle distribuite su molte macchine nel mondo​
Folding@Home
●​ Progetto che ha realizzato un sistema distribuito grazie agli utenti​
●​ Permette l’uso dei loro PC per applicazioni di ricerca scientifica​

Vantaggi dei sistemi distribuiti

●​ Affidabilità: tolleranza ai guasti grazie alla ridondanza​
●​ Integrazione: facile unione di componenti diversi​
●​ Scalabilità: aggiunta di nuovi componenti al crescere delle richieste​
●​ Miglior rapporto prestazioni/prezzo​
●​ Sistema aperto: facile aggiungere nuove funzionalità​ ​ ​ ​ ​
●​ Trasparenza: e molto complicato e comunque si puo usare senza sapere come fuzniona​
●​ facilità: posso aggionrare il servere e gli utenti si collegano senza dover aggiornare anche loro​ ​

Svantaggi dei sistemi distribuiti

●​ Sicurezza: vulnerabilità nella rete e nei dati​
●​ Complessità: programmazione più difficile, gestione dei protocolli​

Classificazione di Flynn (1972)

●​ Basata su:​
○​ Flusso delle istruzioni​
○​ Flusso dei dati​
1.​ SISD (Single Instruction Single Data): un solo core, un solo flusso​
2.​ MISD: non esistono​
3.​ SIMD (Single Instruction Multiple Data): stessa istruzione su più dati (es. GPU)​
4.​ MIMD (Multiple Instruction Multiple Data): sistemi distribuiti​
MIMD prevede 2 modelli:
●​ Modello a memoria condivisa (shared memory model):​
○​ I core eseguono flussi di istruzioni contemporaneamente

​
●​ Modello a scambio di messaggi (message passing model):​
○​ Ogni CPU ha la sua RAM e comunica attraverso la rete​
○​ Tipico dei sistemi distribuiti

Classificazione a layer
Il software di un sistema distribuito è suddiviso in layer:
1.​ Presentation Layer (PL)​
Interfaccia con l’utente: input/output (es. interfacce grafiche) (html e css)​
2.​ Business Logic Layer (BLL)​
Logica dell'applicazione, coordina l’elaborazione dei dati​
3.​ Resource Management Layer (RML)​
Gestione delle risorse, come l’accesso ai database​

Architetture distribuite (dove viene eseguito il SD)

●​ Architettura a 1 Tier​
Tipica degli anni ’70​
Tutto su un'unica macchina → difficile manutenzione
e tutti si connettevano con tastiere e cazzi li ​
●​ Architettura a 2 Tier​
Diffusa dagli anni ’80 con modello client-server​
○​ PL sul client​
○​ RML sul server​
Si distingue tra:​
○​ BLL SU CLIENT: THICK client: più logica sul client​
○​ BLL SU SERVER: THIN client: meno logica sul client

​
 ●​ Architettura a 3 Tier​
Ogni layer è su una macchina diversa:​
○​ PL → Presentation Tier (front-end)​
○​ BLL → Middle Tier​
○​ RML → Data Tier (back-end)​
●​ Architettura a N Tier​
N > 3 tier (es. BLL suddiviso su più livelli)​

SOCKET (come avvengono le connessioni e scambi)

Porta
●​ Numero a 16 bit che identifica un processo/servizio in esecuzione su una macchina​
Indirizzo IP
●​ Identifica un’interfaccia di rete di una macchina in rete​

Protocolli di trasporto
●​ UDP: datagrammi, senza connessione, non affidabile, non garantisce ordine, full-duplex, socket simmetriche​
●​ TCP: stream, orientato alla connessione, affidabile, garantisce ordine dei segmenti, comunicazione full-duplex, socket
assimmetriche​

Socket
●​ Entità software che individua un endpoint in un canale di comunicazione​
●​ Identificato da: indirizzo IP + porta + protocollo​
Tipi:
●​ Socket TCP: orientati alla connessione, stream​
●​ Socket UDP: datagrammi, senza connessione​
●​ Socket RAW: permettono di accedere e modificare ai pacchetti del lv retee realizzare protocolli di diagnostica (es. ping)​

Librerie Java
●​ java.io.*, java.net.*​

Localhost
●​ 127.0.0.1: indica la macchina stessa​
Esempio:
●​ Sul client cambia l’IP ma non il localhost​

Definizione Socket
●​ Entità software usata per permettere l’interconnessione di processi (IPC: Inter Process Communication)​

Famiglie di Socket
●​ AF_INET: per Internet (raw stream e datagram)​
●​ AF_UNIX: per comunicazioni tra processi sulla stessa macchina​

Multicast
●​ Modalità di trasmissione da 1 mittente a più destinatari (selezionati)​
Confronti:
●​ Broadcast: a tutti i nodi della rete​
●​ Unicast: a un solo destinatario​

Motivazione
●​ Multicast = maggiore efficienza nell’utilizzo della rete​
●​ Permette di inviare pacchetti a un gruppo specifico, i router fanno duplicazioni del pacchetti e riducendo l’uso della
banda​

Applicazioni del multicast

●​ Servizi di diffusione di news​
●​ Servizi di videostreaming e videoconferenze​
●​ DNS​
Per funzionare, il multicast necessita di:
●​ Indirizzi IP di classe D per identificare il gruppo di destinatari (224.0.0.0 – 239.x.x.x)​
●​ Supporto del router per la memorizzazione dei componenti del gruppo​
●​ Un protocollo con le seguenti funzioni:​
○​ Aggiunta/rimozione di membri al gruppo​
○​ Invio dei pacchetti al gruppo​
○​ Ricezione dei dati da parte dei membri​

Multicast vs Broadcast
●​ Le socket multicast derivano da quelle datagram, ma con caratteristiche specifiche per l’invio a più destinatari​

Architetture di rete
Client-Server
●​ Processi diversi: uno richiede e l’altro offre un servizio​
●​ Centralizzato​

●​
●​ ip client: dimanici ​
ip server: fisso
●​ client non comunicano tra di loro
Peer-to-Peer (P2P)
●​ formato da peer, host alla pari, host = peer​
●​ Può essere:​
○​ decentralizzato: un peer ha sia funzionalita client che server

○​ Centralizzato: directory server centrale

 server contriene una mappatura ovvero informazioni tra i peer, il servern on ha memoria controlla solo il
contenuto delle cose che si scambiano tra peer, ma non le memorizza​
○​ Ibrido: parzialmente centrallizato, ci sono dei peer elettri tramite un algoritmo di elezione che li rende super
peer e hanno funzionalitad di indicizzazione mentre ci sono gli altri peer a livello piu basso chiamati leaf peer

Evoluzione storica
●​ 1998 – MP3.com: upload di musica propria, architettura client-server​
●​ 1999 – MY.MP3.com: possibilità di ascoltare musica ovunque (anche rippata da CD)​
●​ 2000: cause legali dall’industria discografica​
●​ 1999 – Napster (di Shawn Fanning): condivisione file musicali via P2P​
○​ Architettura P2P centralizzata (ricerca via server centrale)​
●​ 2001: cause legali → chiusura di Napster​

Vantaggi e svantaggi
●​ Vantaggio di Napster: memorizzazione canzoni distribuita​
●​ Svantaggio: se si blocca il server centrale, l’intero sistema si chiude​

2000 – Gnutella
●​ Applicazione distribuita per la condivisione di file​
●​ Architettura P2P pura: ricerca distribuita tra i vicini​
●​ Vantaggio: nessun punto unico di rottura​
●​ Svantaggio: ricerca lenta, consumo di banda e tempo, possibile abuso di connessioni altrui​

2001 – Kazaa
●​ Condivide file con architettura P2P ibrida​
●​ La ricerca viene ottimizzata tramite supernodi​
●​ Cause legali simili a Gnutella per violazione di copyright, ma li lasciano fare perche il problema erano i file condivisi non
il fatto che esisteva effettivamente il software​
2001 – BitTorrent
●​ Condivide file dividendo i file in pezzi​
●​ Gli utenti scaricano pezzi diversi simultaneamente, migliorando velocità​
●​ Risolve il problema del leeching:​

XML (eXtensible Markup Language)

●​ Linguaggio di markup nato per definire la struttura dei dati​
●​ Composto da:​
○​ Markup: tag (es. <titolo>, </titolo>)​
○​ Contenuto: dati tra i tag​
●​ Nasce negli anni ’90 per superare i limiti dell’HTML e definire standard di memorizzazione​

Serializzazione / Deserializzazione
●​ Serializzazione (Marshalling): trasformazione di un oggetto in stringa XML​
●​ Deserializzazione (Unmarshalling): ricostruzione dell’oggetto dalla stringa XML​

Caratteristiche di XML
●​ Standard industriale usato globalmente​
●​ Estensibile: si possono aggiungere tag personalizzati​
●​ Case sensitive​
●​ Condivide caratteristiche con JSON​
●​ Human readable/writable: XML può essere letto, scritto e modificato facilmente​
●​ NON è un linguaggio di programmazione (è solo markup)​
Validabile
●​ Può essere controllato:​
○​ Dal punto di vista sintattico (well-formed): struttura corretta con tag chiusi​
○​ Dal punto di vista semantico (valid): uso corretto dei tag previsti​

XSD (XML Schema Definition)

●​ Definisce la struttura dei tag validi e se sono obbligatori o opzionali​
●​ Serve per validare file XML​

JSON (JavaScript Object Notation)

●​ Formato nato nel 2000 per semplificare la serializzazione/deserializzazione​
●​ Permette di rappresentare oggetti come testo​
●​ Alternativa leggera a XML​

Differenze con XML

●​ JSON è più leggero​
●​ Non usa linguaggio di markup​
As a markup language, XML is more complex and requires a tag structure. In contrast, JSON is a data format that extends from
JavaScript. It does not use tags, which makes it more compact and easier to read for humans. JSON can represent the same
data in a smaller file size for faster data transfer.
Tecnologie per realizzare sistemi distribuiti
●​ Socket: comunicazione tra client e server (es. TCP)​
●​ WWW (World Wide Web):​
○​ Parte di Internet che usa HTTP (livello applicativo)​
○​ Usa browser come interfaccia client​
○​ Server: Apache, Tomcat​
○​ Pagine statiche: contenuti fissi, non modificabili, usate solo per mostrare cose come un libro collegato tra
pagine
○​ Pagine dinamiche: generate da programmi (es. servlet Java) interagibili che cambiano ​

Servlet (Java)
 ●​ Eseguite su un application server (es. Apache Tomcat)​
●​ Producono pagine web dinamiche​

Vantaggi del WWW rispetto ai socket

●​ Interfaccia standard (browser)​
●​ Standardizzazione del protocollo (HTTP)​
●​ Linguaggio semplice (HTML)​
●​ User-friendly​

Svantaggi
●​ Richiede aggiornamenti della conoscenza e della programmazione​

Struttura di un messaggio HTTP

Tra Client e Server (es. browser e Apache)
●​ 3-way handshake TCP​
●​ Esempio:​
○​ Client → GET /data​

○​ Server → HTTP/1.1 200 OK​

I messaggi HTTP possono essere:

●​ Richieste:​
○​ Riga iniziale: metodo + percorso + versione HTTP​
○​ Header (chiave:valore) da info aggiuntive​
○​ Riga vuota​
○​ Body (facoltativo)​
●​ Risposte:​
○​ Riga iniziale: versione + status code + descrizione​
○​ Header​
○​ Riga vuota​
○​ Body (contenuto della risposta, es. pagina HTML)​ ​
○​ contenuto che l’app vuole inviare​

Metodi HTTP
●​ GET: recupera una risorsa (es. pagina o collezione), senza body​
●​ POST: invia dati al server per creare una risorsa all’interno del percorso specificato​

HTTP (HyperText Transfer Protocol)

●​ Protocollo del livello applicativo usato per richiedere e trasferire risorse (es. pagine web)​
●​ Utilizzato dal WWW (dal 1991)​
Protocolli associati
●​ HTTP: trasferimento delle pagine​
●​ HTML: linguaggio per definire le pagine​
●​ URL: identificatore della posizione della risorsa​

URL (Uniform Resource Locator)

●​ Identificativo della risorsa, posizione e metodo di accesso​
URN (Uniform Resource Name)
●​ Nome univoco della risorsa, indipendente dalla posizione​
URI (Uniform Resource Identifier)
●​ Identificativo generico della risorsa (include URL e URN)​
Esempio URI:
●​ urn:isbn:0-486-27557-A → Romeo and Juliet​

Esempio URL scomposto:

HTTP in architettura Client-Server
Versioni principali:
●​ 0.9 (1991)​
●​ 1.0 (1996)​
●​ 1.1 (1999)​
●​ 2.0 (2015)​
●​ 3.0 (2022)​
Funzionamento:
1.​ Handshake TCP​
2.​ Richiesta HTTP​
3.​ Risposta​
4.​ Chiusura TCP​

Metodi HTTP e uso del body

●​ Il body contiene i dati inviati al server (se presente)​
Uso storico
●​ I metodi GET e POST sono stati usati nelle form HTML per inviare dati al server ed eseguire azioni​

Metodo PUT
●​ Richiede di creare o aggiornare la risorsa al percorso indicato​
●​ Il contenuto è nel body​
Metodo DELETE
●​ Richiede che la risorsa presente al percorso venga rimossa​
●​ Non ha body​

Mappatura metodi HTTP e operazioni CRUD

●​ Create → POST​
●​ Retrive→ GET​
●​ Update → PUT​
●​ Delete → DELETE​

Con il post i dati non vengono messi nell’url ma nel body e sono cifrati
Tipologie di HEADER
●​ Generali: date, connection​

●​ Del body: content-type, content-length usano il MIME

●​ Della richiesta: host, user-agent, accept, ecc.​
●​ Della risposta: server​

MIME (multipurpose internet mail expansion) Type

●​ Specificano il tipo di contenuto​
○​ text/html​

○​ text/plain​

○​ image/jpeg​

○​ application/json​

CGI (Common Gateway Interface)

●​ Applicazioni scritte in Python, Perl o altri linguaggi che producono output su stdout​
●​ Vengono avviate da un web server al ricevimento di richieste HTTP​

Funzionamento CGI
1.​ Il client invia una richiesta HTTP con i parametri​
2.​ Il web server avvia la CGI, passando i parametri in STDIN​
3.​ La CGI elabora e produce output​
4.​ L’output viene passato al web server​
5.​ Il web server risponde al client​

JAVA e portabilità
●​ Codice Java viene eseguito su JVM (Java Virtual Machine)
●​ JDK include il JRE​
●​ La JRE (Java Runtime Environment) consente di eseguire classi Java e contiene librerie e il JVM
questo rende java portabile su qualsiasi macchina​

Servlet
●​ Oggetti Java eseguiti lato server (in un container)​
x elaborare richieste http, produce contenuto web dinamico
●​ Gestiti dal web server che esegue la JRE​

Vantaggi delle servlet rispetto alle CGI

●​ Portabilità: usa Java​
●​ Il container gestisce automaticamente il multithreading e la sicurezza​
●​ Più efficiente: le CGI creano un processo per ogni richiesta, mentre le servlet usano un thread per ogni richiesta​
●​ La programmazione è più semplice, si concentra solo sull’elaborazione (es. metodi doGet, doPost)
●​ caricate una volta sola e poi eseguono thread, mentre le CGI venogno mosse da harddisk a ram ogni richiesta
Metodi delle servlet
●​ init(): inizializzazione, eseguita una sola volta quando la servlet è caricata​
●​ service(): eseguito a ogni richiesta​
○​ In HttpServlet, sovrascritto tramite doGet, doPost​

●​ destroy(): eseguito quando si rimuove la servlet (es. aggiornamento)​

Oggetti utili:
●​ HttpServletRequest e HttpServletResponse: contengono parametri della richiesta e della risposta​

Versioni HTTP
●​ 1991 – Versione 0.9​
○​ solo get, nessun header​
●​ 1996 – Versione 1.0​
 ○​ Introduzione di metodi (GET, POST) e header

questa cosa veniva fatta ogni richiesta ​

●​ 1997 – Versione 1.1​
○​ Standardizzata, aggiunge connessione persistente​
■​ Connection: keep-alive​

■​ Connection: close per chiudere la connessione dopo la risposta​

Connessione client-server (TCP)

3 way handshake, richiesta rispostam
1.​ SYN​
2.​ SYN + ACK​
3.​ ACK​
4.​ Richiesta e risposta HTTP​

Modalità di funzionamento
●​ Incanalata: richieste/risposte una dopo l’altra​
●​ Pipelining: invio di più richieste senza attendere la risposta​

Problemi
●​ Pipelining difficile da usare con i proxy server (server intermediari)​
●​ Head-of-line blocking:​
○​ Se una risposta tarda ad arrivare, blocca tutte le successive​
​
2.0
introduce multiplexxing =

risolve l’head of blocking, con una sola connessione venivano spezzettate le richieste e composta la risposta a pezzi per poi
mandarla indietro
aveva comunque problemi di packed loss
3.0
utilizza QUIC al posto di TCP ed era basato su UDP fatto da google
questo permette di gestire le connessioni con piu velocita quidni meno latenza e meno packed loss, gestiva anche meglio il
problema dell’head of blocking grazie alla sua velocita
gestisce anche meglio le connessioni wifi

Possibili soluzioni ai limiti HTTP 1.1

●​ Pipelining: permettere più connessioni parallele verso lo stesso dominio (max 6)​
○​ Domain Sharding: dividere le risorse su più sottodomini, ciascuno con 6 connessioni​
●​ CSS Sprite: un’unica immagine contenente più risorse, poi suddivisa lato client​

HTTP/2 – Versione 2.0 (2015)

●​ Multiplexing: gestione di più stream indipendenti su un’unica connessione TCP​
○​ Evita l’incanalamento​
○​ Risolve Head-of-Line Blocking​
●​ Le risposte non sono più bloccate da richieste precedenti​
●​ Server push: il server può inviare risposte non richieste per velocizzare l’interazione​
●​ Tutto avviene tramite TLS (HTTPS)​

HTTP/3 – Versione 3.0 (2020)

●​ Usa il protocollo UDP + QUIC:​
○​ Evita il 3-way handshake TCP​
○​ Permette connessioni più rapide​
○​ Stream indipendenti​
●​ Introduce identificativo di connessione:​
 ○​ Consente di mantenere la sessione attiva anche in caso di cambio rete​

Status Code HTTP

●​ Inseriti negli header​
●​ Formato: codice numerico + messaggio​
HTTP/1.1 – Categorie principali
Categoria Codici Significato

1xx 100-199 Informational

2xx 200-299 Success

3xx 300-399 Redirection

4xx 400-499 Client Error

5xx 500-599 Server Error

Esempio: 200 OK, 404 Not Found, 500 Internal Server Error
​
HTTP è stateless
●​ Ogni richiesta HTTP è indipendente dalle altre​
●​ Per mantenere la persistenza dei dati si usano:​
○​ Sessioni​
○​ Cookie​

Cookie (lato client)

●​ Salvati automaticamente dal browser​
●​ Il client li invia nelle richieste successive al server​
Sessione (lato server)
●​ Identificata tramite Session ID​
●​ Il server mantiene i dati lato server, il client invia solo l’ID​

JSP (Java Server Pages)

●​ Linguaggio di scripting Java lato server​
●​ Consente di scrivere codice Java in frammenti direttamente in pagine HTML rendendole dinamiche​
Funzionamento
●​ Alla richiesta della JSP, viene convertita in servlet​
●​ Gestita dal container come una servlet​
●​ Il controllo degli errori e la compilazione avvengono sulla servlet generata​

Vantaggi delle JSP

●​ Più semplice da programmare​
●​ Ideale per chi non ha conoscenze approfondite di Java​
●​ Adatta come parte principale della logica lato presentazione​

TAG JSP
●​ <%! ... %> → Dichiarazioni (visibilità globale)​
●​ <% ... %> → Scriptlet (istruzioni eseguite, visibilità locale)​
●​ <%= ... %> → Espressioni (valutate e inserite nel risultato)​
●​ <%@ ... %> → Direttive (es. import, configurazioni)​

JSP e oggetti predefiniti

●​ In JSP gli oggetti request, response, cookie, session, ecc. sono già automaticamente disponibili​

Come fare una richiesta HTTP

 ●​ Client invia una richiesta HTTP​
●​ Server (Servlet) riceve e risponde con HTTP​
●​ L’applicazione Java può usare:​
○​ URL, METHOD, HEADER, BODY​

Esempio:
HttpURLConnection conn = (HttpURLConnection) new URL("http://172.18.80.8:90/getHello").openConnection();

Web Services (Servizi Web)

Definizione
●​ Funzionalità accessibili via Internet (porte 70/80)​
●​ Basati sul concetto di client-server​
Evoluzione
1.​ Nasce il Web (HTML, HTTP, URL)​
2.​ Pagine statiche​
3.​ Pagine dinamiche​
4.​ Tecnologie diverse per ogni parte delle web app → problema di compatibilità​
Problema
●​ Troppe tecnologie diverse → difficile integrazione tra servizi​
Soluzione
●​ Standardizzazione:​
○​ Formato dei messaggi: es. JSON/XML​
○​ Meccanismi di invio: es. HTTP​
○​ Interfacce pubbliche per accedere ai dati (API)​

Web Service (WS)

●​ Applicazioni web accessibili tramite Internet​
●​ realizzate tramite framework che rendono disponibili Interfacce pubbliche (API) permettono l’invio di richieste e
l’utilizzo di funzionalita e i dati del web services tenendo nascosto il modo nel quale queste funzionalita funzionano, si
usano ebasta
API (Application Programming Interface)
●​ Espongono funzionalità tramite URL​
●​ Due principali standard:​
○​ SOAP​
○​ REST​

SOAP (Simple Object Access Protocol)

●​ Protocollo per i Web Services (WS)​
●​ Utilizza HTTP POST​
●​ I dati sono nel body della richiesta, scritto in SOAP variante XML​
●​ Permette di eseguire metodi remoti (RPC – Remote Procedure Call)​

REST (Representational State Transfer)

●​ Architettura WS più leggera​
●​ Si basa su URL + HTTP methods (GET, POST, PUT, DELETE) per operare sulle risorse​
●​ Legato al modello CRUD(Create, Read, Update, and Delete)​

WS-SOAP e SOA (Service Oriented Architecture)

Parte SERVER
●​ Definisce l’interfaccia pubblica con le funzionalità​
●​ Implementa le funzionalità​
●​ Pubblica l’interfaccia sul Service Registry usando WSDL (Web Services Description Language)​
●​ WSDL descrive:​
○​ Le operazioni disponibili​
 ○​ I messaggi (input/output) e i loro parametri​
○​ Gli url e header da usare​

Parte CLIENT
●​ Cerca il servizio nel Service Registry tramite UDDI (universal description descovery integration)​ ​
●​ Scarica il file WSDL​
●​ Genera il client stub (interfaccia Java del servizio)​
●​ Sviluppa e usa l’applicazione client
●​ richiamando metodi STUB veongo inviate richieste SOAP (richieste post con body SOAP variante xml)​

Scambio messaggi in SOAP

●​ Le richieste usano HTTP POST​
●​ Il contenuto è XML​
Struttura:
SERVICE
├── porte (porttype)
└── operazioni
├── messaggi input (parametri + type)
└── messaggi output

Binding
●​ Collegamento tra un’operazione astratta e un protocollo concreto (es. HTTP)​

Problemi con WS-SOAP

●​ SOAP è troppo rigido, basato solo su XML​
●​ Richiede protocolli intermedi e strutture complesse​
Soluzione
●​ Uso di REST:​
○​ Linee guida semplici​
○​ Formati leggeri (es. JSON)​
○​ Nessun protocollo intermedio​

REST (Representational State Transfer)

●​ Architettura basata su linee guida​
●​ Ogni risorsa è identificata con un URL​
●​ Le API sviluppate secondo questi principi sono dette RESTful​
Esempio:
https://xilosoft.it/profilo/nicoladallapozza/2024/12/23
●​ URL action-based (SOAP)​
●​ URL resource-based (REST)​

Principi fondamentali di REST

1.​ Le risorse sono contenute nel server, identificate univocamente da URL​
2.​ Le risorse possono essere modificate con metodi HTTP (CRUD)​

CRUD e metodi HTTP

●​ GET: recupera una risorsa (non ha body)​
●​ PUT: sostituisce una risorsa esistente con quella nel body​
 ●​ DELETE: elimina la risorsa​
●​ POST: aggiunge una nuova risorsa​
⚠️ POST non è idempotente (la stessa richiesta può produrre effetti diversi)
Classificazione
●​ GET = lettura​
●​ POST, PUT, DELETE = scrittura​
Le operazioni GET, PUT e DELETE sono idempotenti
si possono fare piu volta senza problema danno lo stesso risultato

deployment da container ad avviare servlet

RESTful WS/API – Principi

●​ Le risorse (singole o collezioni) sono identificate da un URI​
●​ Per modificarle si usano direttamente i metodi CRUD:​
○​ GET, POST, PUT, DELETE​
●​ Ogni risorsa può avere più rappresentazioni​
○​ Es. JSON, XML, plain text, HTML​
●​ La risorsa è l’informazione​
●​ La rappresentazione è il formato in cui è restituita​

Header HTTP per i formati:

●​ Accept: specifica i formati che il client accetta​
●​ Content-Type: indica il formato del corpo della richiesta​

Altri principi REST

●​ Le interazioni client-server sono stateless:​
○​ Ogni richiesta è indipendente​
○​ Lo stato viene gestito dal client (es. con cookie)​
●​ Favorisce la scalabilità del sistema distribuito​
●​ Le risposte possono contenere link a URI per automatizzare le iterazioni​

HATEOAS
Hypermedia As The Engine Of the Application State​
→ Permette al client di scoprire dinamicamente le azioni disponibili tramite link presenti nella risposta

ti arriva la risposta e ci sono link e riferimenti ad altre shit