Analisi dei requisiti

Questa `e un’attivit`a preliminare allo sviluppo o alla modifica di un sistema software, il cui scopo `e quello di definire le funzionalit`a che il nuovo prodotto o il prodotto modificato deve offrire, ovvero i requisiti che devono essere soddisfatti dal software sviluppato. I requisiti si possono dividere in requisiti funzionali che descrivono le funzionalit`a ed i servizi forniti dal sistema e i requisiti non funzionali che non sono collegati direttamente con le funzioni implementate dal sistema, ma piuttosto alle modalit`a operative e di gestione definendo ad esempio vincoli sullo sviluppo del sistema.

Requisiti funzionali

• Estendere le funzionalit`a principali di NILDE per essere accessibili e fruibili da altri sistemi come ad esempio software di Document Delivery o applicazioni Mobile.

• Possibilit`a di utilizzare le API REST di NILDE tramite chiamate AJAX in Cros Domain.

• Per utilizzare le API NILDE `e obbligatorio richiedere una chiave di applicazione (API Key e Secret).

• Per i servizi pubblici non `e richiesta l’autenticazione, ma viene richiesta l’API Key e il Secret per consentire l’accesso a tali servizi solamente ad alcuni sistemi.

• Per i servizi privati `e necessaria l’autenticazione con il proprio account NILDE, (utenti e biblioteche); `e inoltre necessaria una chiave di ac- cesso APY Key e Secret da richiedere al gestore. Per questi servizi l’autenticazione verr`a implementata utilizzando il protocollo OAuth. • Le API Key e il Secret sono diverse per ogni sistema che vorr`a utilizzare

le API NILDE e andranno indicate come parametri in tutte le chiamate REST a NILDE.

3.1 NILDE 3. Analisi dello scenario di riferimento • API Key e Secret possono essere richieste al gestore di NILDE compi-

lando un apposito form.

• Il formato della risposta (anche in caso di errore) di una chiamata REST verso NILDE sar`a XML contenente un messaggio .

Requisiti non funzionali

• Le API NILDE utilizzate per implementare i servizi offerti, verranno esposte publicamente sul sito di NILDE in modo tale che chiunque potr`a documentarsi e utilizzarle previa la richiesta di un API key e Secret che verr`a fornita solo previa autorizzazione.

• Il tempo di risposta a una chiamata REST utilizzando le API messe a disposizione non dovr`a superare l’ordine dei 5 secondi.

• Le API sviluppate dovranno rispettare i vincoli e i principi dei servizi REST.

• Essendo NILDE un’ applicazione web sviluppata utilizzando il linguag- gio di programmazione PHP, tutti i metodi che si andranno a svilup- pare dovranno essere programmati utilizzando lo stesso linguaggio di programmazione.

• Garantire l’autenticit`a dell’applicazione e/o dell’utente che effettua la chiamata ai servizi utilizzando le API NILDE.

• Il sistema deve essere facilmente espandibile, e adattabile alle future esigenze.

Progettazione e sviluppo servizi

REST in NILDE

In questo capitolo verr`a esposta la soluzione software sviluppata per im- plementare i servizi di NILDE che vengono resi fruibili attraverso un’insieme di API pubbliche e private con le quali `e possibile accedere alle funzionalit`a del sistema. Come `e possibile vedere dalla Figura 4.1, l’architettura software di NILDE `e stata estesa in riferimento alla figura 3.4 in modo da aggiun- gere queste nuove funzionalit`a che garantiscono un’aumento della scalabilit`a dell’intero sistema e assicurano un elevata interoperabilit`a con altri sistemi.

96 4. Progettazione e sviluppo servizi REST in NILDE

Figura 4.1: Architettura software NILDE + API.

Nel riquadro tratteggiato, vengono indicati appunto gli strati software che sono stati inseriti nel sistema per permettere lo sviluppo delle API REST. Il blocco API indica appunto l’insieme dei servizi (vedi paragrafo 4.5) messi a disposizione da NILDE, mentre il blocco grigio sta ad indicare i framework utilizzati per la creazione dei servizi REST e per la gestione dell’autenti- cazione / autorizzazione realizzata tramite l’utilizzo di OAuth. Il riquadro NILDE Mobile indica lo sviluppo futuro di un Applicazione Mobile o di un sito Mobile che sfrutterebbe le API REST per fornire i servizi all’utente che desidera interagire con l’applicazione o con il sito Mobile. Infine il riquadro XML indica che i dati scambiati (esempio le risposte alle chiamate API) ven- gono rappresentati attraverso l’utilizzo del linguaggio XML (Vedi paragrafo 1.2.3).

Nel corso di questo capitolo, verranno descritti i principali framework esistenti utilizzati per facilitare lo sviluppo delle API REST e infine ver- ranno trattati nel dettaglio i servizi sviluppati focalizzando lo studio sulla definizione delle risorse, dei parametri previsti nelle chiamate API e sulla progettazione delle risposte del server in caso di chiamate con esito positivo o negativo.

4.1

Descrizione della migrazione

In questo paragrafo viene descritto cosa `e stato realizzato per questo lavo- ro di tesi, analizzando le scelte implementative e le tecnice utilizzate. Come `e stato gi`a detto, lo scopo di questo lavoro `e quello di rendere NILDE accessibi- le dall’esterno in modo da permettere a utenti di interagire con le funzionalit`a del sistema. Si `e pensato quindi di estendere l’architettura software esistente basandosi sul paradigma architetturale REST i cui principi hanno permesso l’implementazione di un set di servizi pubblici e privati:

• le API pubbliche di NILDE, permettono di interagire con il sistema attraverso le chiamate a metodi che non richiedono autenticazione ma che necessitano l’utilizzo di una API key e un Secret che dovranno essere richiesti al gestore e rilasciati previa autorizazione.

• le API private invece oltre a richiedere l’utilizzo della API key e del Secret, necessitano dell’autenticazione con il proprio account NILDE per interagire con i servizi.

API key e Secret, possono essere richieste al gestore di NILDE compilando un apposito form (URL), sono diversi per ogni sistema / utente che vorr`a utilizzare le API di NILDE e andranno indicati come parametri obbligatori in tutte le chiamate REST a NILDE.

Per entrambi i servizi (Pubblici e Privati), la gestione dell’autenticazione e autorizzazione attraverso API key e Secret per e API pubbliche e API key, secret + username e password per le API private, verr`a implementata utilizzando il protocollo OAuth[24] (vedi paragrafo 4.3). In particolare per le API private per le quali `e richiesta l’autenticazione, verr`a richiesto di effettuare il login tramite un form.

Si `e reso necessario per`o apportare una modifica al metodo di gestio- ne dell’autenticazione in quanto per alcuni sistemi che dovranno interagire con NILDE risulta scomodo effettuare il login tramite l’inserimento dei dati nel form. Per cui `e stata sviluppata la funzionalit`a di Direct Login con la

98 4. Progettazione e sviluppo servizi REST in NILDE

quale `e possibile specificare le credenziali di accesso (username e password) direttamente nel’URL della chiamata API. La password in questo caso, verr`a codificata utilizzando l’algoritmo MD51.

Le chiamate alle API di NILDE potranno essere effettuate attraverso l’utilizzo di AJAX in Cros Domain. Questo `e stato implementato grazie all’utilizzo della specifica CORS (vedi paragrafo 4.4.1.3 e 4.6) che permette a un server di distinguere la provenienza di una richiesta e decidere se servirla. Nei prossimi paragrafi verr`a spiegato con maggior dettaglio tecnico come queste funzionalit`a sono state implementate in NILDE.