API REST
REST
Nel modello REST (Representational State Transfer) la risorsa è una struttura dati, descritta tramite un modello ed un formato. L’API mette a disposizione l’accesso a questa risorsa tramite una interfaccia standard di comandi, che resta identica qualsiasi sia il tipo di risorsa.
I principali comandi previsti sono:
- GET: effettua una query di ricerca di una o più istanze della risorsa
- POST: aggiunta di una nuova istanza
- DELETE: eliminazione di una istanza
- PATCH/PUT: modifica di una istanza esistente.
Questi comandi corrispondono quindi alle operazioni CRUD (Create Read Update Delete) di un modello dati come un database.
Questa API utilizza direttamente i verbi della richiesta HTTP.
Rest quindi:
- definisce una interfaccia standard comune per qualsiasi tipologia di oggetto;
- questa interfaccia corrisponde dal punto di vista logico a operazioni CRUD;
- questa interfaccia corrisponde dal punto di vista della comunicazione a verbi http: in particolare i verbi e codici di risposta sono gli stessi dello standard http;
- le chiamate/risposte REST sono, come le chiamate http, senza stato, quindi sia i messaggi di richiesta che di risposta devono fornire tutto il contesto, senza presupporre sessioni attive.
Esempio di REST
In questo tipo di esercizio, dato un determinato prodotto da realizzare, si andrà a progettare una applicazione distribuita basata su web e servizi REST che prevede i seguenti passaggi:
1) Identificazione entità e relazioni e disegno del database con tabelle
2) Identificazione delle viste e dei servizi REST
3) Disegno dei tracciati JSON
4) Disegno dell’architettura dell’applicazione (quindi dei principali moduli dell’app distribuita).
Esempio: realizzare una applicazione distribuita che gestisce una TODO list. Gli elementi della TODO list prevedono un titolo, una data di scadenza, e uno stato (completato/non completato). L’applicazione client mostrerà la lista delle TODO, permetterà di inserire una nuova TODO, permetterà di cancellare una TODO da quelle esistenti e permetterà di modificarne lo stato.
Vediamo la realizzazione:
1) Identificazione di entità e relazioni:
In questo progetto è prevista una sola entità, quindi una sola tabella TODO.
| Nome campo | funzione |
id: int | id univoco |
title: varchar | titolo |
dueDate: date | data di scadenza |
completed: bool | stato di completamento |
Sono previste 4 query (oltre alla CREATE):
– INSERT into TODO (id, title, dueDate, completed) VALUES ($id, $title, $dueDate, $completed)
– SELECT id, title, dueDate, completed FROM TODO
– UPDATE TODO set completed=$completed WHERE id=$id
– DELETE TODO WHERE id=$id
2) Identificazione delle viste e dei servizi REST
I dati da mostrare corrispondono a quelli presenti nella tabella TODO.
I servizi REST saranno i seguenti:
| URL | Verbo | Azione |
{baseUrl}/todo | GET | Riceve tutte le TODO |
{baseUrl}/todo | POST | Aggiunge una TODO |
{baseUrl}/todo/$id | PUT | Modifica una todo con id=$id(per cambiarne lo stato) |
{baseUrl}/todo/$id | DELETE | Elimina una TODO con id=$id |
In questo caso non prevediamo la GET di una singola TODO.
3) Disegno dei tracciati JSON.
La struttura dati del JSON nella response di GET/POST/PUT è questa:
{
todos: [
{
id: $id,
title: $title,
date: $dueDate,
completed: $completed
},
...
]
}4) Disegno dell’architettura della web application:
