{"id":5853,"date":"2019-02-11T10:00:12","date_gmt":"2019-02-11T09:00:12","guid":{"rendered":"https:\/\/www.addlance.com\/blog\/?p=5853"},"modified":"2021-02-17T23:33:09","modified_gmt":"2021-02-17T22:33:09","slug":"architettura-rest-api","status":"publish","type":"post","link":"https:\/\/seven.addlance.com\/beta\/blog\/architettura-rest-api\/","title":{"rendered":"Architettura REST, le Pratiche di buona Progettazione"},"content":{"rendered":"<p><img decoding=\"async\" class=\"alignright wp-image-5855 size-medium\" title=\"architettura REST\" src=\"https:\/\/www.addlance.com\/wp-content\/uploads\/2019\/02\/architettura-rest-300x200.jpg\" alt=\"architettura REST\" width=\"300\" height=\"200\" srcset=\"https:\/\/seven.addlance.com\/beta\/blog\/wp-content\/uploads\/2019\/02\/architettura-rest-300x200.jpg 300w, https:\/\/seven.addlance.com\/beta\/blog\/wp-content\/uploads\/2019\/02\/architettura-rest-1024x683.jpg 1024w, https:\/\/seven.addlance.com\/beta\/blog\/wp-content\/uploads\/2019\/02\/architettura-rest-768x512.jpg 768w, https:\/\/seven.addlance.com\/beta\/blog\/wp-content\/uploads\/2019\/02\/architettura-rest-1536x1024.jpg 1536w, https:\/\/seven.addlance.com\/beta\/blog\/wp-content\/uploads\/2019\/02\/architettura-rest-2048x1365.jpg 2048w, https:\/\/seven.addlance.com\/beta\/blog\/wp-content\/uploads\/2019\/02\/architettura-rest-610x407.jpg 610w, https:\/\/seven.addlance.com\/beta\/blog\/wp-content\/uploads\/2019\/02\/architettura-rest-1080x720.jpg 1080w\" sizes=\"(max-width: 300px) 100vw, 300px\" \/>Prima di parlare nel dettaglio di Architettura REST, fermiamoci un attimo sulle API. Nonostante lavori in questo campo da quasi venticinque anni, non posso evitare che la prima immagine a venirmi in mente leggendo questo termine sia quella dell&#8217;imenottero giallo e nero che svolazza in un campo di fiori colorati. Mentre API \u00e8 l&#8217;acronimo di <strong><em>Application Programming Interface.<\/em><\/strong> \u00c8 il modo con cui componenti <em>software<\/em> stabiliscono regole di comunicazione, un&#8217;interfaccia che consente il dialogo tra parti diverse di uno stesso <em>software<\/em> o tra parti di programmi diversi.<\/p>\n<p>Le API nascono con lo scopo di permettere allo sviluppatore di <strong>usare lo stesso codice in diversi contesti.<\/strong><\/p>\n<p><!--more--><\/p>\n<ul>\n<li>Ci sono API che permettono al PC di eseguire le attivit\u00e0 richieste chiamando le varie librerie di sistema<\/li>\n<li>Ci sono le API di <strong>Facebook, Twitter, Instagram, Google<\/strong> dette <strong><em>API Oauth<\/em><\/strong> e utilizzate per l\u2019autenticazione<\/li>\n<li>Ci sono le API di <strong>Ebay, Amazon<\/strong> e dei vari <em>e-commerce<\/em> e altre ancora.<\/li>\n<\/ul>\n<p>Ma tutto questo <em>ronzare<\/em> quando \u00e8 cominciato?<\/p>\n<h2>SOA o API? La differenza \u00e8 nell&#8217;orientamento dell&#8217;architettura<\/h2>\n<p>All&#8217;inizio del secolo le grandi aziende cominciavano e mettere online i loro grandi DB (<em>database<\/em>) e le applicazioni. Questa tendenza si \u00e8 espressa inizialmente nell&#8217;architettura orientata ai servizi (<strong>SOA<\/strong>), mentre pi\u00f9 recente \u00e8 stata l&#8217;evoluzione delle <strong>API<\/strong> orientate al web e i vari stili di disegno.<\/p>\n<p>Vediamo le differenze:<\/p>\n<ul>\n<li>La differenza tecnica fondamentale \u00e8 che l\u2019approccio SOA si focalizza sulla creazione di servizi web che facilitano le interazioni interne, <em>server-to-server<\/em>, mentre le API web sono destinate prevalentemente alla creazione di applicazioni web e mobile, quindi all&#8217;interazione con i clienti.<\/li>\n<li>In genere i programmi SOA sono avviati dai reparti IT e <strong>finalizzati al risparmio sui costi<\/strong>, mentre i programmi API hanno origine solitamente dai reparti di <em>business development<\/em> e puntano a generare nuovi flussi di ricavi.<\/li>\n<li>La maggior parte dei progetti SOA viene creata da e per gli <strong>architetti aziendali<\/strong>, per semplificare l&#8217;integrazione di sistemi eterogenei e la distribuzione di nuovi servizi IT. I programmi API hanno invece come obiettivo la soddisfazione delle esigenze degli <strong>sviluppatori,<\/strong> delle <strong>applicazioni <\/strong>e degli <strong>utenti<\/strong>.<\/li>\n<\/ul>\n<h2>Le API e l&#8217;architettura REST, un modello orientato alle risorse<\/h2>\n<p>Ma andiamo oltre e arriviamo all&#8217;architettura REST. REST sta per <strong><em>Representational State Transfer<\/em><\/strong> ed \u00e8 uno stile nel disegno delle API. <strong>Indica la rappresentazione del trasferimento di stato di un dato qualsiasi:<\/strong><\/p>\n<ul>\n<li>il credito residuo della tua scheda telefonica<\/li>\n<li>un\u2019immagine<\/li>\n<li>la lista dei tuoi contatti su un <em>social network,<\/em> ecc.<\/li>\n<\/ul>\n<p>Si tratta di uno stile architetturale, quindi, non di un protocollo. Qual \u00e8 la differenza? Un protocollo definisce i dettagli di implementazione di un rapporto, uno stile architetturale ne delinea i requisiti. Ad esempio, uno stile architetturale pu\u00f2 definire la regola \u201ci <em>client<\/em> possono contattare i <em>server,<\/em> ma non il contrario\u201d. A livello pi\u00f9 basso nella scala di astrazione c&#8217;\u00e8 il protocollo che specifica come e con che regole, il<em> client<\/em> pu\u00f2 contattare il<em> server,<\/em> ad esempio attraverso il<strong> protocollo HTTP<\/strong>.<\/p>\n<p style=\"text-align: center;\">Leggi anche <a href=\"https:\/\/www.addlance.com\/blog\/web-service\/\">Web Service rest o soap, la guida per scoprirlo<\/a><\/p>\n<p>Ora scendiamo dal filosofico al pratico. Il modello REST \u00e8 orientato alle risorse: si applica cio\u00e8 ad una risorsa che pu\u00f2 essere un documento, un&#8217;immagine, un concetto o una persona, ma anche un&#8217;operazione o un servizio.<\/p>\n<p>Ad esempio: <strong><em>https:\/\/www.mioecommerce.it\/clienti\/3 <\/em><\/strong>\u00e8 un URI che risponde alla chiamata inviando i dati del cliente con identificativo 3. Ogni risorsa deve essere identificata in modo univoco e la URI\u00a0 <strong><em>https:\/\/www.mioecommerce.it\/clienti\/3<\/em> <\/strong>fa proprio questo.<\/p>\n<p>&nbsp;<\/p>\n<h2>I 5 principi dell&#8217;architettura REST (e il 6\u00b0 facoltativo)<\/h2>\n<p>L&#8217;architettura REST \u00e8 definita in 5 principi (il sesto \u00e8 facoltativo):<\/p>\n<ul>\n<li><strong>Client\/Server<\/strong> &#8211; Stabilisce il concetto di separazione delle competenze in cui il <em>server<\/em> offre una o pi\u00f9 risorse e rimane in attesa di richieste da parte del <em>client<\/em> che vuole accedere alla risorsa. Queste richieste possono essere accettate o meno.<\/li>\n<li><strong>Assenza di stato<\/strong> &#8211; Ogni richiesta deve contenere tutte le informazioni necessarie per essere elaborata, senza aver bisogno di riferimenti alle precedenti richieste. Quindi le interazioni tra <em>client <\/em>e <em>server<\/em> devono essere senza stato in modo da migliorare la <strong>scalabilit\u00e0<\/strong> e l&#8217;<strong>affidabilit\u00e0.<\/strong><\/li>\n<li><strong>Caching<\/strong> &#8211; Al fine di migliorare l&#8217;efficienza della rete, \u00e8 possibile memorizzare il risultato di una richiesta da parte del <em>client<\/em> in modo da diminuire la latenza dei tempi di risposta.<\/li>\n<li><strong>Stratificazione<\/strong> &#8211; \u00e8 possibile inserire dei livelli tra <em>client<\/em> e <em>server<\/em> sotto forma di componenti intermediari, i quali trasmettono i messaggi e possono offrire ulteriori servizi (<em>caching<\/em> e sicurezza ad esempio). Ogni livello \u00e8 visibile solo dal suo immediato vicino in modo da essere disaccoppiati tra loro e <strong>migliorare la flessibilit\u00e0<\/strong> in caso di aggiornamenti. Lo svantaggio principale dei sistemi a strati \u00e8 nell&#8217;aumento dei tempi di risposta.<\/li>\n<li><strong>Interfaccia uniforme <\/strong>&#8211; \u00c8 la propriet\u00e0 che definisce l&#8217;insieme delle operazioni permesse sulle risorse e quella che contraddistingue lo stile architetturale REST da altre architetture di rete. Questo permette al <em>client <\/em>di identificare la risorsa e interagire con essa. Frequente \u00e8 l&#8217;uso del <strong>protocollo HTTP<\/strong> tramite le operazioni come PUT, GET, POST e DELETE. Le condizioni che permettono la definizione di un&#8217;interfaccia uniforme sono:<\/li>\n<\/ul>\n<ol>\n<li><strong>individuazione delle risorse<\/strong> (tramite URI)<\/li>\n<li><strong>manipolazione delle risorse<\/strong> attraverso le loro rappresentazioni: una rappresentazione \u00e8 un gruppo di dati (e metadati) di solito auto-descrittivo, ad es. un documento XML oppure JSON. Quando un <em>client <\/em>accede a una risorsa, non gli viene restituita la risorsa, ma piuttosto una sua rappresentazione. Inoltre, per aggiornare una risorsa, un componente pu\u00f2 comunicare la rappresentazione desiderata della risorsa<\/li>\n<li><strong>messaggi autodescrittivi<\/strong>: ogni messaggio contiene tutte le informazioni necessarie per essere processato<\/li>\n<li>il <em>client<\/em> deve essere responsabile del mantenimento del proprio stato e pu\u00f2 effettuare una transizione solo attraverso <em>hyperlinks<\/em>.<\/li>\n<\/ol>\n<ul>\n<li><strong>Codice su richiesta<\/strong> &#8211; Un <em>client<\/em> ha la possibilit\u00e0 di estendere le sue funzionalit\u00e0 attraverso il <em>download<\/em> e l&#8217;esecuzione di <em>applet <\/em>o <em>script<\/em> (cosa che avviene ad esempio quando carichiamo una pagina con js). Semplifica i <em>client<\/em> e aumenta le possibilit\u00e0 di estensione.<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<h2>I 4 vantaggi dell&#8217;architettura REST<\/h2>\n<p><strong>1. Separazione:<\/strong> il protocollo REST rende completamente indipendenti il <em>client <\/em>e il <em>server.<\/em> Questo permette di separare il lavoro tra chi sviluppa e quindi l&#8217;evoluzione indipendente delle diverse componenti degli sviluppi. Inoltre, \u00e8 possibile sostituire il componente <em>frontend<\/em> senza modificare una riga di codice del <em>backend <\/em>e viceversa.<\/p>\n<p><strong>2. Portabilit\u00e0<\/strong>: l&#8217;interfaccia REST utilizzata da un&#8217;applicazione web pu\u00f2 essere riutilizzata senza nessuna modifica per lavorare con un&#8217;applicazione mobile.<\/p>\n<p><strong>3. Scalabilit\u00e0<\/strong>: il sistema pu\u00f2 essere scalato facilmente, ad un qualsiasi livello dell&#8217;architettura, con pochissima difficolt\u00e0 e con nessun impatto per i livelli precedenti e successivi.<\/p>\n<p><strong>4. Indipendenza<\/strong>: L&#8217;API REST \u00e8 sempre indipendente dal tipo di piattaforma e questo conferisce notevole libert\u00e0 nella scelta del linguaggio o <em>framework<\/em> per l&#8217;implementazione. Un set API RESTful (per RESTful si intende un set di API che rispetta tutti i vincoli visti in precedenza) \u00e8 possibile scriverlo in codice <strong>PHP, Java, Python o Node.js<\/strong> o qualsiasi altro. \u00c8 fondamentale quindi che le risposte alle richieste avvengano sempre nel formato stabilito per lo scambio di informazioni, ad es. JSON.<\/p>\n<p>&nbsp;<\/p>\n<h2>L&#8217;architettura REST e suoi (ancora) ampi spazi di evoluzione<\/h2>\n<p>L&#8217;architettura REST \u00e8 ormai una pratica abbastanza diffusa, ma nonostante la sua solidit\u00e0, mantiene ampi spazi di evoluzione. <strong>Non \u00e8 possibile definire uno standard di modellazione<\/strong>, perch\u00e9 ogni architetto\/designer ha il suo stile. Si pu\u00f2 fare arte anche disegnando un set di API RESTful.<\/p>\n<p><em>Guest post a cura di Alessandro Testa <\/em><\/p>\n<p>&nbsp;<\/p>\n<p>&nbsp;    \t<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Le API e l&#8217;architettura REST. Differenze, peculiarit\u00e0, limiti e sviluppi futuri, cos\u00ec come le racconta ad AddLance l&#8217;ingegnere informatico Alessandro Testa<\/p>\n","protected":false},"author":5,"featured_media":5855,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_et_pb_use_builder":"","_et_pb_old_content":"","_et_gb_content_width":""},"categories":[17],"tags":[18],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/seven.addlance.com\/beta\/blog\/wp-json\/wp\/v2\/posts\/5853"}],"collection":[{"href":"https:\/\/seven.addlance.com\/beta\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/seven.addlance.com\/beta\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/seven.addlance.com\/beta\/blog\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/seven.addlance.com\/beta\/blog\/wp-json\/wp\/v2\/comments?post=5853"}],"version-history":[{"count":1,"href":"https:\/\/seven.addlance.com\/beta\/blog\/wp-json\/wp\/v2\/posts\/5853\/revisions"}],"predecessor-version":[{"id":10830,"href":"https:\/\/seven.addlance.com\/beta\/blog\/wp-json\/wp\/v2\/posts\/5853\/revisions\/10830"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/seven.addlance.com\/beta\/blog\/wp-json\/wp\/v2\/media\/5855"}],"wp:attachment":[{"href":"https:\/\/seven.addlance.com\/beta\/blog\/wp-json\/wp\/v2\/media?parent=5853"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/seven.addlance.com\/beta\/blog\/wp-json\/wp\/v2\/categories?post=5853"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/seven.addlance.com\/beta\/blog\/wp-json\/wp\/v2\/tags?post=5853"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}