Una volta spiegato come individuare una risorsa abbiamo bisogno di un meccanismo per indicare quali operazioni effettuare su di esse. Il principio dell'uso esplicito dei metodi HTTP ci indica di sfruttare i metodi (o verbi) predefiniti di questo protocollo, e cioè GET, POST, PUT e DELETE.
Facciamo un semplice esempio per provare a chiarire questo concetto. Quando inseriamo un URI nella barra degli indirizzi di un browser stiamo in realtà chiedendo al browser di eseguire un metodo HTTP sulla risorsa individuata dall'URI. Il metodo che implicitamente stiamo eseguendo è GET, il cui effetto è l'accesso ad una rappresentazione della risorsa identificata dall'URI.
Dal punto di vista del codice, non avremo bisogno di un metodo del tipo getCliente(1234) per ottenere la rappresentazione del cliente con codice 1234, sarà sufficiente sfruttare il metodo standard GET del protocollo HTTP sull'URI che identifica quel determinato cliente.
Questo rende uniforme l'invocazione di operazioni sulle risorse, cioè il client non ha bisogno di sapere qual è la specifica interfaccia da utilizzare per invocare il metodo che consente di ottenere la rappresentazione di un cliente. In un contesto non RESTful potremmo avere metodi come getCliente() o getCustomer() o altra specifica dipendente dalle scelte di chi ha sviluppato il Web Service.
In un contesto RESTful sappiamo già a priori come ottenere la rappresentazione di una risorsa. In altre parole, questo principio REST stabilisce una mappatura uno a uno tra le tipiche operazioni CRUD (creazione, lettura, aggiornamento, eliminazione di una risorsa) e i metodi HTTP.
| Metodo HTTP | Operazione CRUD | Descrizione |
|---|---|---|
| POST | Create | Crea una nuova risorsa |
| GET | Read | Ottiene una risorsa esistente |
| PUT | Update | Aggiorna una risorsa o ne modifica lo stato |
| DELETE | Delete | Elimina una risorsa |
È opportuno notare che questo principio è in contrasto con quella che è la tendenza generale nell'utilizzo dei metodi HTTP. Infatti, molto spesso viene utilizzato il metodo GET per eseguire qualsiasi tipo di interazione con il server. Ad esempio, spesso per l'inserimento di un nuovo cliente nell'ambito di un'applicazione Web viene eseguita una richiesta di tipo GET su un URI del tipo:
http://www.myapp.com/addCustomer?name=Rossi
Questo approccio non è conforme ai principi REST perchè il metodo GET serve per accedere alla rappresentazione di una risorsa e non per crearne una nuova. In pratica questo uso del metodo GET introduce un effetto collaterale che, tra l'altro, può avere delle conseguenze indesiderate se, ad esempio, l'URI viene invocato più volte o se la risorsa viene memorizzata in uno dei vari livelli di cache esistenti tra client e server.
Come principio generale, nel progettare un Web Service in modalità REST è utile evitare l'uso di verbi negli URI ma limitarsi ad utilizzare nomi, ricordandosi che un URI identifica una risorsa.
Allo stesso modo è opportuno sottolineare che il corpo di una richiesta HTTP con metodi PUT e POST è pensato per il trasferimento della rappresentazione di una risorsa e non per eseguire chiamate remote o altre attività simili.