Guida comandi linux

L'articolo Guida ai comandi Linux più utilizzati da Terminale sembra essere il primo su Cesare Bordi | Innovation Manager & Back-end Developer.

Architettura REST: cos’è?

Additional constraints can then be applied to form a new architectural style that better reflects the desired properties of a modern Web architecture.

REST vede la luce dieci anni dopo la nascita del World Wide Web, piattaforma per la condivisione di documenti distribuiti su server connessi tra loro. L’acronimo REST (REpresentational State Transfer) viene introdotto nel 2000 nella tesi “Architectural Styles and the Design of Network-based Software Architectures” di Roy Fielding definendo così uno stile architetturale basato sul Web che fissa un insieme di principi per la progettazione di un sistema hypermedia distribuito.

REST è quindi un modello di progettazione e non va confuso con un protocollo (non definisce messaggi) nè con una specifica (non definisce uno standard), ma opera ad un livello di astrazione superiore.
Non è quindi del tutto corretto confrontarlo con il protocollo SOAP anche se entrambi sono oggi ampiamente usati nello sviluppo dei Web Service.

In estrema sintesi:

REST detta le regole per creare una piattaforma per l’elaborazione distribuita dei dati sfruttando l’architettura Web già dotata di tutto ciò che occorre: da una parte un’infrastruttura basata su protocolli ben definiti (HTTP in primis) dall’altra le informazioni viste come risorse mappate univocamente (URI).

I principi dell’architettura REST

Iniziare con un approccio “Null Style”

Il “Null Style” è il punto di partenza: un sistema in cui non ci sono confini distinti tra i componenti (risorse) che andranno connessi. I seguenti principi dell’architettura REST rappresentano i vincoli per standardizzare l’accesso alle risorse distribuite in questo scenario.

Client-Server

L’architettura REST applica il paradigma SoC (Separation of Concerns), “separazione dei compiti“, al sistema di funzionamento Client-Server (Richiesta-Risposta). Il vincolo Client-Server favorisce un’architettura distribuita in cui lo sviluppo applicativo lato client è indipendente da quello lato server. Questo spiega anche perché REST non si preoccupa dei linguaggi e dei metodi di sviluppo.

Stateless

La comunicazione tra utente del servizio (client) ed il servizio (server) deve essere priva di stato: ogni richiesta del client deve contenere tutte le informazioni necessarie al server per comprendere la richiesta e non deve sfruttare informazioni di sessione memorizzate sul server. E’ il client a gestire la sessione e, se necessario, dovrà ricevere opportune informazioni nella risposta del server.
Il vincolo stateless ha benefici sul monitoraggio delle richieste, sull’affidabilità e sulla scalabilità: non dovendo mantenere dati in sessione sarà più facile scalare orizzontalmente il servizio creando istanze parallele poste dietro ad un load balancer.

Cache

Nell’architettura REST il vincolo di Cache impone che le risposte siano etichettate come memorizzabili nella cache o meno. L’utilizzo della cache da parte di client, server o componenti middleware consente di ridurre le interazioni con la rete a tutto vantaggio delle performance.

Uniform Interface

L’architettura REST impone un vincolo di uniformità dell’interfaccia di accesso ai dati gestiti dal servizio, svincolandolo dalla specifica implementazione sottostante. Questo deve avvenire attraverso ulteriori sotto-vincoli.

Identificazione delle risorse

In REST ogni informazione è una risorsa, vista come qualsiasi cosa possa essere nominata: un documento, un’immagine, il meteo di oggi, …
Una risorsa può essere mutabile (l’ultima revisione di un documento) o immutabile nel tempo (la specifica revisione di un documento), l’unica cosa che deve essere statica è la semantica della sua mappatura, per questo motivo viene data una grande importanza all’identificazione univoca di una risorsa (URI) e alla necessità di mantenerla nel tempo.
Tale sotto-vincolo sottolinea lo scopo organizzativo proprio dei nomi di domino Internet.

Rappresentazione delle risorse

Una risorsa può essere rappresentata in molti modi diversi (HTML, XML, JSON, SVG, JPG, …) attraverso dati, metadati descrittivi ed eventuali “control data“. I dati di controllo possono definire lo scopo di un messaggio di richiesta o risposta, il suo comportamento o stato. Ad esempio possono specificare come gestire la cache di una riposta o la necessità di creare una risorsa sulla base dei dati e delle caratteristiche presenti nella richiesta.

Collegamenti tra risorse

L’architettura REST è pensata per connettere risorse tramite collegamenti ipertestuali. Questo principio è anche noto come HATEOAS (Hypermedia As The Engine Of Application State). Un Client deve quindi apprendere dalla rappresentazione di un risorsa fornita dal server (risposta) l’eventuale relazione con ulteriori risorse.
Ad esempio, richiedendo una fattura, la risposta dovrebbe contenere anche il link alla relativa anagrafica cliente.

Layered System

Un’architettura REST prevede più livelli architettonici, indipendenti l’uno dall’altro, frapposti fra client e server.
Gli strati intermedi possono avere scopi specifici durate il transito dei dati come ad esempio la sicurezza, il caching o il balancing.
I livelli potranno essere modificati in base all’evolversi dello scenario.

Code-On-Demand

L’ultimo vincolo di code-on-demand è facoltativo e consente ad un’implementazione REST di estendere le funzionalità del client scaricando ed eseguendo il codice sotto forma di applet o script. Ciò appare oggi abbastanza scontato e potrebbe rendere questo vincolo facoltativo quasi paradossale, ma non lo era nel 2000 quando i contenuti Web erano per lo più pagine statiche renderizzate dal browser.

Differenza tra architettura REST ed servizio RESTful

Eroneamente usati come sinonimi, REST è il nome dello “stile architetturale” mentre RESTful viene utilizzato per qualificare un Web Service che rispetta i vincoli dell’architettura REST.

Architettura REST: i contro

• L’architettura REST si può applicare solo in ambito Web a differenza del protocollo SOAP.
• A causa del vincolo stateless c’è la possibilità di un aumento dei dati di ambiente restituiti ripetutamente in una serire di richieste (overhead per interazione). Il vincolo di Cache cerca di compensare questo aspetto.
• A causa del vincolo stateless, spostando il controllo sul client si riduce il controllo da parte del server sul comportamento coerente dell’applicazione.

L'articolo Architettura REST per sviluppare Web Service sembra essere il primo su Cesare Bordi | Innovation Manager & Back-end Developer.

Il codice proposto dallo stesso WordPress che solitamente si utilizza per abilitare il rewriting e far così scomparire dalla url “index.php” è il seguente:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

Questa regola eseguirà il rewrite di ogni percorso della url sott’intendendo la presenza di /index.php

Problema: può però essere necessario escludere una cartella (o più) da questa regola generale per caricare ad esempio file che devono essere accessibili attraverso un link diretto o script di varia utilità.

Soluzione: è possibile modificare la regola in modo da segnalare una directory (o più) che faccia eccezione rispetto alla regola generale attraverso la seguente istruzione:

RewriteCond %{REQUEST_URI} !^/(Cartella1|Cartella2|Cartella3).*$

Ecco come apparirà il blocco di codice completo:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_URI} !^/(Cartella1|Cartella2|Cartella3).*$
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

L'articolo WordPress: escludere una cartella dal rewriting url di Apache sembra essere il primo su Cesare Bordi | Innovation Manager & Back-end Developer.

Problema: come disabilitare il directory browsing di Apache2?

Soluzione: per prima cosa bisogna aprire il file della configurazione di default di apache2, nel mio caso denominato “000-default.conf” e rimuovere dalle options il modulo “Indexes” appunto.

Quindi troveremo una riga simile a questa:

Options Includes Indexes FollowSymLinks MultiViews

che diventerà:

Options Includes FollowSymLinks MultiViews

poi dovremo riavviare il servizio:

sudo service apache2 reload

Non sempre questo unico accorgimento risolve il problema, quindi consiglio di lanciare i seguenti comandi per disabilitare il modulo autoindex di Apache:

sudo a2dismod autoindex
sudo service apache2 restart

L'articolo Apache directory browsing: disabilitare la visualizzazione delle cartelle sembra essere il primo su Cesare Bordi | Innovation Manager & Back-end Developer.