SoapUI RESTful - Metodi HTTP

I metodi HTTP più comunemente usati sono POST, GET, PUT, PATCH e DELETE. Questi corrispondono rispettivamente alle operazioni di creazione, lettura, aggiornamento ed eliminazione (o CRUD). Esistono anche molti altri metodi, tuttavia vengono utilizzati meno frequentemente. Tra questi metodi, OPTIONS e HEAD sono usati più spesso di altri.

INVIARE

Il metodo POST viene utilizzato per creare nuove risorse. Viene utilizzato per creare risorse subordinate. Cioè, subordinato a qualche altra risorsa (ad esempio genitore).

In altre parole, quando si crea una nuova risorsa, POST al genitore e il servizio si occupa di associare la nuova risorsa al genitore, assegnando un ID (nuovo URI della risorsa), ecc.

In caso di creazione riuscita, restituire lo stato HTTP 201, restituendo un'intestazione di posizione con un collegamento alla risorsa appena creata con gli stati HTTP 201.

POST non è né sicuro né idempotente. È quindi consigliato per richieste di risorse non idempotenti.

L'esecuzione di due richieste POST identiche comporterà due risorse contenenti le stesse informazioni. A volte, genera un messaggio di errore in base al tipo di servizi definiti.

OTTENERE

Il metodo HTTP GET viene utilizzato per leggere o recuperare una rappresentazione di una risorsa. In caso di risposta positiva, GET restituisce una rappresentazione in XML o JSON e un codice di risposta HTTP 200 (OK). In un caso di errore, molto spesso restituisce un 404 (NON TROVATO) o 400 (RICHIESTA ERRATA).

Secondo la progettazione della specifica HTTP, le richieste GET (insieme a HEAD) vengono utilizzate solo per leggere i dati e non per modificarli. Pertanto, GET è considerato sicuro.

GET può essere chiamato senza il rischio di modifica o danneggiamento dei dati: chiamarlo una volta ha lo stesso effetto di chiamarlo 10 volte. Inoltre, GET è idempotente, il che significa che fare più richieste identiche porta ad avere lo stesso risultato di una singola richiesta.

Si consiglia di non esporre operazioni non sicure tramite GET - non dovrebbe mai modificare alcuna risorsa sul server.

METTERE

PUT viene utilizzato per aggiornare le risorse esistenti. PUT viene utilizzato come URI di risorsa noto con il corpo della richiesta che contiene la rappresentazione aggiornata della risorsa originale.

PUT può essere utilizzato anche per creare una risorsa in cui l'ID della risorsa viene scelto dal client anziché dal server. In altre parole, se PUT viene utilizzato come URI che contiene il valore di un ID risorsa inesistente.

Il POST viene utilizzato per creare nuove risorse e fornire l'ID definito dal client nella rappresentazione del corpo. In caso di aggiornamento riuscito, restituisce 200 (o 204 se non restituisce alcun contenuto nel corpo) da un PUT.

Se PUT viene utilizzato per la creazione, restituisce lo stato HTTP 201 in caso di creazione riuscita. Un corpo nella risposta è facoltativo.

PUT non è un'operazione sicura, poiché modifica (o crea) lo stato sul server, tuttavia è idempotente. Se l'utente crea o aggiorna una risorsa utilizzando PUT e quindi effettua di nuovo la stessa chiamata, la risorsa è ancora lì e ha lo stesso stato della prima chiamata.

Si consiglia di mantenere le richieste PUT idempotenti. Si consiglia vivamente di utilizzare POST per richieste non idempotenti.

PATCH

PATCH viene utilizzato per modificare le capacità. La richiesta PATCH deve solo contenere le modifiche alla risorsa, non la risorsa completa. Assomiglia a PUT, ma il corpo contiene una serie di istruzioni che descrivono come una risorsa attualmente residente sul server dovrebbe essere modificata per produrre una nuova versione.

Ciò significa che il corpo PATCH non dovrebbe essere solo una parte modificata della risorsa, ma dovrebbe essere in un qualche tipo di linguaggio patch come JSON Patch o XML Patch.

PATCH non è né sicuro né idempotente. Una richiesta PATCH può essere emessa in modo tale da essere idempotente, il che aiuta anche a prevenire risultati negativi dalle collisioni tra due richieste PATCH sulla stessa risorsa in un lasso di tempo simile.

Le collisioni da più richieste PATCH possono essere più pericolose delle collisioni PUT poiché alcuni formati di patch devono funzionare da un punto base noto, altrimenti danneggeranno la risorsa.

I client che utilizzano questo tipo di applicazione patch dovrebbero utilizzare una richiesta condizionale in modo tale che la richiesta non riesca, se la risorsa è stata aggiornata, dall'ultimo accesso del client alla risorsa.

ELIMINA

DELETE viene utilizzato per eliminare una risorsa identificata da un URI. In caso di eliminazione riuscita, restituisce lo stato HTTP 200 (OK) insieme a un corpo della risposta, rappresentazione dell'elemento eliminato. Altrimenti, restituisce lo stato HTTP 204 (NESSUN CONTENUTO) senza corpo di risposta.

In altre parole, uno stato 204 senza corpo o la risposta in stile JSEND e lo stato HTTP 200 sono le risposte consigliate.

Dal punto di vista delle specifiche HTTP, le operazioni DELETE sono idempotenti. Se l'utente elimina una risorsa, viene rimossa. Chiamare ripetutamente DELETE sulla stessa risorsa finisce con lo stesso risultato: la risorsa è sparita.

Chiamare DELETE su una risorsa una seconda volta restituirà spesso un 404 (NON TROVATO), poiché era già stato rimosso e quindi non è più reperibile. Ciò rende le operazioni DELETE non più idempotenti, tuttavia lo stato finale della risorsa è lo stesso. La restituzione di un 404 è accettabile e comunica accuratamente con lo stato della chiamata.