7 HTTP metodi che ogni sviluppatore web dovrebbe sapere e come test

Mai chiesti quale sia la differenza tra GET e POSTrichieste, o quando usare PUT? Non sei sola. Avere una comprensione di base dei diversi metodi HTTP, o verbi, un APIsupports è una conoscenza utile quando si esplorano e testano le API.

In questo post, discuterò come viene utilizzato ogni metodo HTTP e come incorporarli nel test API.

HTTP Metodi

• GET
• POST
• PUT
• HEAD
• DELETE
• PATCH
• OPTIONS

FATTI

GET le richieste sono le più comuni e ampiamente utilizzati metodi di Api andwebsites. In poche parole, il metodo GET viene utilizzato per recuperare i dati da aserver alla risorsa specificata. Ad esempio, supponiamo di avere un APIwith un /users endpoint. Effettuare una richiesta GET a tale endpoint dovrebberorestituire un elenco di tutti gli utenti disponibili.

Poiché una richiesta GET richiede solo dati e non modifica alcuna risorsa, è considerata un metodo sicuro e idempotente.

Testare un’API con richieste GET

Quando si creano test per un’API, il metodoGET sarà probabilmente il tipo di richiesta più frequente fatta dai consumatori del servizio, quindi è importante controllare ogni endpoint noto con una richiesta GET.

A livello base, queste cose dovrebbero essere convalidate:

• Controlla che una richiesta GET valida restituisca un 200 codice di stato.
• Assicurati che una richiesta GET a una risorsa specifica restituisca i correctdata. Ad esempio,GET /users restituisce un elenco di utenti.

GET è spesso il metodo predefinito nei client HTTP, quindi la creazione di test per queste risorse dovrebbe essere semplice con qualsiasi strumento scelto.

POST

Nei servizi Web,POST le richieste vengono utilizzate per inviare dati all’APIserver per creare o udpare una risorsa. I dati inviati al server sono memorizzati nel corpo della richiesta HTTP.

L’esempio più semplice è un modulo di contatto su un sito web. Quando si compilano gli input in un modulo e si preme Invia, i dati vengono inseriti nel corpo della risposta della richiesta e inviati al server. Questo forse JSON, XML o parametri di query (ci sono molti altri formati,ma questi sono i più comuni).

Vale la pena notare che una richiesta POST non è idempotente. Modifica i dati sul server backend (creando o aggiornando aresource), al contrario di una richiesta GET che non modifica alcun dato. Ecco una grande spiegazione di idempotentcy.

Testare un’API con richieste POST

Il secondo metodo HTTP più comune che incontrerai nei tuoi test API èPOST. Come accennato in precedenza, le richiestePOST vengono utilizzate perinviare i dati al server API e creare o aggiornare una risorsa. Dal momento che le richieste POST modificano i dati,è importante avere test API per tutti i metodi POST.

Ecco alcuni suggerimenti per testare le richieste POST:

• Crea una risorsa con una richiestaPOST e assicurati che venga restituito un codice di stato200.
• Quindi, effettuare una richiestaGET per quella risorsa e assicurarsi che i dati siano stati salvati correttamente.
• Aggiungere test che assicuranoPOST le richieste non riescono con dati errati o mal formattati.

Per ulteriori idee su testingscenarios API comuni,controlla questo post.

PUT

Simlar a POST,PUT le richieste vengono utilizzate per inviare dati all’API toupdate o creare una risorsa. La differenza è che le richieste di input sono idempotenti. Thatis, chiamando la stessa richiesta PUT più volte produrrà sempre lo stesso risultato. Al contrario, chiamare ripetutamente una richiesta postavere effetti collaterali della creazione della stessa risorsa più volte.

in generale, quando un PUT richiesta crea una risorsa che il server willrespond con un 201Created), e se la richiesta modifiesexisting risorsa che il server restituirà un 200OK) o 204NoContent).

Testare un’API con richieste PUT

Testare un’APIPUT metodi è molto simile al test POSTrequests. Ma ora che conosciamo la differenza tra i due (idempotenza), possiamo creare test API per confermare questo comportamento.

Controlla queste cose durante il test delle richieste PUT:

• Chiamando ripetutamente una richiestaPUT restituisce sempre lo stesso risultato(idempotente).
• Il codice di stato corretto viene restituito durante la creazione e l’aggiornamentouna risorsa (ad esempio,201o200204).
• Dopo aver aggiornato una risorsa con una richiesta PUT, una richiesta GET perquesta risorsa deve restituire i dati corretti.
• PUT le richieste dovrebbero fallire se vengono forniti dati non validi in therequest — nulla dovrebbe essere aggiornato.

PATCH

APATCH request è uno dei metodi HTTP meno noti, ma lo includo così in alto nella lista poiché è simile a POST andPUT. La differenza con PATCH è che si applicano solo modificazioni parziali alla risorsa.

La differenza tra PATCH e PUT, è quellala richiesta di PATCH non è idempotente (come una richiesta POST).

Per espandere la modifica parziale, supponiamo che l’API abbia un endpoint/users/{{userid}} e che un utente abbia un nome utente. Con la richiesta aPATCH, potrebbe essere necessario inviare solo il nome utente aggiornato nel corpo della richiesta, al contrario di POST e PUT che richiedono l’entità fulluser.

Testare un’API con richieste di PATCH

Poiché il metodoPATCH è così semplice da POSTARE e METTERE, si applicano molte delle stesse tecniche di test. È comunque importante convalidare il comportamento di qualsiasi endpoint API che accetti questo metodo.

Cosa cercare quando si testano le richieste di PATCH:

• Una richiestaPATCH deve restituire un2xx codice di stato.
• PATCH le richieste dovrebbero fallire se vengono forniti dati non validi in therequest — nulla dovrebbe essere aggiornato.

La semantica delle richieste di PATCH dipenderà in gran parte dall’API specifica che stai testando.

ELIMINA

IlDELETE metodo è esattamente come sembra: elimina la risorsa all’URL specificato. Questo metodo è uno dei più comuni in RESTfulAPIs quindi è bene sapere come funziona.

Testare un’API con le richieste di CANCELLAZIONE

DELETE le richieste dovrebbero essere pesantemente testate poiché generalmente vengono rimosse da un database. Fare attenzione quando si testano i metodi di ELIMINAZIONE, assicurarsi che si stiano utilizzando le credenziali corrette e non testare con i dati realuser.

Un tipico caso di test per una richiesta di ELIMINAZIONE sarebbe simile a questo:

1. Creare un nuovo utente con un POST richiesta /users
2. Con l’id utente restituito dal POST fare un DELETE richiesta /users/{{userid}}
3. Una successiva GET richiesta /users/{{userid}} dovrebbe restituire un errore 404 not found codice di stato.

Inoltre, l’invio di una richiesta di CANCELLAZIONE a una risorsa sconosciuta shouldreturna non-200 codice di stato.

HEAD

Il metodo HEAD è quasi identico a GET, tranne senza il corpo della risposta. In altre parole, seGET /users restituisce un elenco di utenti, alloraHEAD /users farà la stessa richiesta ma non recupererà l’elenco degli utenti.

Le richieste HEAD sono utili per verificare quale richiesta GET verrà restituita prima di effettuare effettivamente una richiesta GET, come beforedownloading di un file di grandi dimensioni o responsebody. Ulteriori informazioni sulle richieste HEAD su MDN.

Vale la pena sottolineare che non tutti gli endpoint che supportano GET supporteranno HEAD – dipende completamente dall’API che stai testando.

Testare un’API con richieste HEAD

Effettuare richieste API con metodiHEAD è in realtà un modo efficace per verificare semplicemente che una risorsa sia disponibile. È goodpractice avere un test per le richieste HEAD ovunque si disponga di un testfor GET requests (purché l’API lo supporti).

Controlla queste cose durante il test di un’API con richieste HEAD:

• Verificare andcheckHTTP intestazioni returnedfrom una richiesta HEAD
• Fare affermazioni contro il codice di stato della TESTA richieste
• le richieste di prove con varie query parametesr per garantire la APIresponds

un Altro utile caso per HEAD requestsisAPI prova del fumo-fare una richiesta HEAD contro ogni endpoint API per garantire che’reavailable.

OPZIONI

Ultimo ma non meno importante abbiamoOPTIONS richieste. Le richieste di OPZIONI sono uno dei miei preferiti, anche se non così ampiamente utilizzato come gli altri HTTPmethods. In poche parole, una richiesta di OPZIONI dovrebbe restituire datadescribing quali altri metodi e operazioni supporta il server nell’URL specificato.

Le richieste di opzioni sono più liberamente definite e utilizzate rispetto alle altre,rendendole un buon candidato per testare gli errori API fatali. Se anAPI non si aspetta una richiesta di OPZIONI, è bene inserire una caseina di test che verifichi il comportamento in errore.

Il test di un’API con richieste di OPZIONI

Il test di una richiestaOPTIONS dipende dal servizio web; whetheror non lo supporta e ciò che dovrebbe restituire definirà come dovresti testarlo.

Come per convalidare un endpoint utilizzando OPZIONI:

• in primo luogo, verificare le intestazioni di risposta e il codice di stato della richiesta
• endpoint di Prova che non supportano OPZIONI e assicurarsi che failappropriately

Ulteriori risorse

Quello che ho descritto sopra è solo un punto di partenza per scavare nel visitare il sitohttp metodi e prove varie risorse di API. Assume anche un caso per lo più ideale: nel mondo reale, le API non sono strutturate come gli esempi sopra. Questo rende il test di vari metodi contro un modo efficace APIan per trovare bug inaspettati.