Web services "RESTful" e servizi di informazione

Per anni i "web services" sono stati identificati con SOAP e XML-RPC, e creare ed utilizzare i web services era considerata cosa da programmatori esperti, il che ha senza dubbio limitato l'adozione su larga scala di questa tecnologia.

Negli ultimi anni, molti grandi protagonisti del web (1)  hanno iniziato ad offrire API remote attraverso web services "RESTful" (2) .
Utilizzare i web services RESTful è molto semplice: ogni funzione ha una URL e può accettare o meni dei parametri. Una richiesta HTTP a quella URL ottiene una risposta in un determinato formato, di solito HTML o XML. Naturalmente usare XML consente un'elaborazione più avanzata della risposta, mentre usare HTML permette di incorporare facilmente (ma in modo meno personalizzabile) la risposta in una pagina web. Nel caso di XML, l'adozione di set di metadati largamente usati, ormai stanard de facto, come RSS, Dublin Core ecc. semplifica molto il parsing e consente il riutilizzo del codice e una facile integrazione di risposte fornite da web services diversi..

La minima quantità di informazioni necessaria per accedere ai web services RESTful (la URL, eventualmente i parametri previsti e il formato della risposta - che può anche essere dedotto dalla risposta stessa) fa sì che questa tecnologia sia molto "loosely coupled" (si dice di sistemi che non sono troppo strettamente interdipendenti) . "Loose coupling" e "hackability" sono due concetti che vanno insieme: sono stati identificati come due tipi di approccio che distinguono il Web 2.0 dal Web 1.0 (3) e si sono dimostrati molto efficaci nell'attrarre nuovi utenti verso i servizi.

In comunità in cui la condivisione delle informazioni è ancora agli inizi e / o le risorse e le competenze sono limitate, l'utilizzo di web services RESTful, accompagnato dall'adozione di set di metadati comuni, è il modo più facile, più efficiente ed economico di realizzare servizi informativi in collaborazione.

Il tipo più semplice e più conosciuto di web service sono i flussi RSS: sono accessibili ad una URL, a volte accettano parametri per creare dinamicamente la risposta, e rstituiscono una risposta XML con un set standard di metadati.
Un altro modo efficace di sfruttare REST per la condivisione delle informazioni è realizzare architetture distribuite basate sul modello dell'Open Archive Initiative.

Un paio di esempi di servizi di informazione basati su REST nel settore dell'agricoltura:

- AgriFeeds
This is an agricultural news and events aggregator. It aggregates news items from several feeds and allows for the creation of aggregated custom feeds that can be called at special URLs with special parameters for customization.
The metadata sets used are RSS for news and RSS extended with a special Application Profile

- The ARD Web Ring Database of organizations on EGFAR
This relies on HTTP calls to special URLs accepting one or more parameters and returning an XML or HTML response.
The system does not rely on a common metadata set for the moment, but a common Application Profile will be adopted very soon. Also, additional parameters for improved search options will be added.


Notes:

(1) Google e Amazon. per esempio. Tanto per dare un'idea del cambiamento di approccio ai web services, recentemente i distributori della famosa piattaforma PEAR per il plug-in di moduli in php ha cessato i web services SOAP e gli aggiornamenti adesso sono disponibili solo tramite REST.

(2) REST significa ... e sono tecnologie RESTful quelle che si basano su transazioni "stateless" (senza stato), come ad esempio le richieste HTTP stateless. Molto spesso ormai REST viene identificato tout-court con le richieste HTTP stateless.

(3) vd. Tim O'Reilly, "What is Web 2.0"

Sviluppo web
© 2007 - 2020 Valeria Pesce
Twitter icon
Facebook icon
LinkedIn icon
Del.icio.us icon
StumbleUpon icon
Digg icon
Reddit icon
Technorati icon