E’ da un pò di tempo che volevo scrivere un articolo sulle architetture basate su REST. In primo luogo perchè nel mio primo post ho menzionato tante tecnologie e volevo piano piano coprirle tutte con articoli ad hoc e poi perchè credo che per risolvere problemi non sempre è necessario ricorrere a soluzioni tecnicamente “imponenti” e dal nome altisonante (pensate solo a quanti standard ruotano intorno alle SOA: SOAP, WSDL, UDDI, ebXML, BPEL, WS-*…) a volte bastano soluzioni “più semplici” architetturalmente ma non meno valide.
Dunque innanzitutto REST (che sta per Representational State Transfer) è un stile architetturale che cerca di “ingabbiare” le caratteristiche del Web che ne hanno decretato il suo successo. Ammetto che la frase sembra un pò da fanatico ma se andiamo a prendere la definizione di REST data dal suo ideatore Roy Fielding:
“Representational State Transfer is intended to evoke an image of how a well-designed Web application behaves: a network of web pages (a virtual state-machine), where the user progresses through an application by selecting links (state transitions), resulting in the next page (representing the next state of the application) being transferred to the user and rendered for their use.”
erano quelli di definire l’architettura stato-transazionale che “movimenta” il web.
Se pensiamo ad un web service sviluppato con SOAP non dovremmo dimenticarci che dopotutto si sta parlando di un risorsa che ha un URL (o meglio URI) e che riceve in input e restituisce in output un XML su HTTP. E allora perchè invece di usare SOAP non usiamo un xml senza vincoli standard e si si potesse far leva sulle peculiarità del protocollo HTTP: per esempio HTTPS e HTTP authentication per gestire la sicurezza end-to-end o l’HTTP caching per migliorare le performance della risorsa; ecco questo in sintesi è REST, veramente molto in sintesi dato essendo una serie di principi architetturali questi non si esauriscono con 3 parole, ma neanche con un tomo di specifiche, verificare per credere nella tesi di dottorato di Fielding.
Nel prossimo articolo parlerò più approfonditamente del perchè nelle WOA viene usato REST, per ora vi lascio con uno spunto di riflessione, quando è necessario usare SOAP al posto di REST?…di seguito trovate un interessante traccia nel blog del progetto Glassfish
Stavo preparando un post che parlava di tutt’altro ma, rispondendo al commento di Simone sul post di Virgilio, mi sono accorto che il mio commento stava diventando troppo lungo.
Quando Simone parla di fallimento del RUP ho avuto un tuffo al cuore…. Il RUP è usatissimo in nord europa in aziende di dimensioni medio-grandi anche non di informatica come ad es. la Volvo (viene usato nelle loro sezioni IT).
Il fallimento del RUP è dovuto al fatto che in Italia molti leggono commenti di consulenti ed altri paper ma nessuno si è preso la briga di studiare la documentazione a corredo della suite di Rational che spiega bene che cos’è il RUP. A me purtroppo è capitato all’università e sinceramente mi ha fatto cambiare la maniera di vedere le cose. Ho visto semplicemente che tutti i problemi legati in qualche modo al software erano se non risolti almeno trattati dal RUP. Anche Simone si fa prendere dal “sentito dire” ed afferma che si deve usare solo per grandi progetti. Allora mi chiedo, perchè la Rational nella documentazione del RUP ha fatto un profilo chiamato “Small Project”?? Io l’avevo seguito per l’esame di ingegneria del software e si tratta di scrivere 14 artefatti di cui 2 opzionali ed alcuni molto brevi (nei 14 c’è anche il glossario per intenderci). Inoltre ci sono diversi articoli che parlano proprio di ciò come ad esempio: questo
(continua…)
Diciamocelo, il post del lunedì è sempre il più facile. Non mi ricordo nulla di cosa ci siamo detti la scorsa settimana e quindi parlo di quello che mi passa per la testa 
Oggi metodologie. Evitando di pestare i piedi a Giorgio che prima o poi ci parlerà concretamente dello sviluppo software.
Oh, dimenticavo, i dettagli si trovano ovunque in rete, qui vi racconto cosa ho (intra)visto per esperienza, per il resto iniziate dai siti di riferimento:
Provo a raccontarvi la mia esperienza personale:
(continua…)
Oggetto di un articolo di Linux Journal di febbraio (accesso a pagamento), l’accesso a filesystems Linux da Windows tramite LTools.
(continua…)
Segnalazione per Snap, un motore di ricerca che:
- presenta a sinistra un elenco di risultati ed a destra la preview del singolo risultato evidenziato,
- permette di dare un giudizio al sito evidenziato.
- permette di navigare il sito in preview senza cambiare pagina,
- raccoglie dati sulla navigazione da utilizzare poi nei ranking successivi.
In altre parole, propongono di abbandonare il modello “elenco di 10.000 risultati da decifrare uno ad uno a partire da un abstract” a favore di un modello in cui l’utente giudica visivamente quanto restituito dalla ricerca e, partendo dal comportamento di navigazione nella preview stessa, ricava informazioni quali il tempo di permanenza ed il tipo di azioni intraprese su di essa. Informazioni utilizzate poi nelle ricerche successive.
Fate un po’ di prove e tornate a commentare con le vostre esperienze…
Visto le recente discussioni, verbali, sul blog, wordpress, i ping,… vi posto alcuni links interessanti con definizioni varie:
- [1] gestione dei commenti, trackback, pingback,…
- [2] permalinks
magari ci sono 10.000 siti che ne parlano, ma mi ero incuriosito dalle chiacchere di domenica sera e oggi su punto informatico trovo due link (1 e 2) su un giro di prova che stanno facendo
stay tuned
Per curiosità ho tenuto sott’occhio il file di log del server web subito dopo un post su wordpress, il quale ha la configurazione di default di ping al sito rpc.pingomatic.com, ed ecco il risultato:
02:48:58 - invio del POST
02:48:59 - esecuzione del PING
(continua…)
… in cui la squadra New Ideas ho ancora molte difficoltà a fare tutti i 90′…
Poche interessanti parole che possono chiarirci sule motivazioni del perché in Italia sia così difficile riuscire anche solo a far formalizzare le idee innovative, figuriamoci realizzarle e farci su un business…
(ovviamente la questione non si esaurisce lì…)
