REST API-klient / -testare

Skriv och skicka HTTP-begäranden med frågeparametrar, rubriker, JSON-/formulärinnehåll och Basic- eller Bearer-autentisering, och granska sedan status, tidtagning och formaterade JSON-svar. Importera ett befintligt cURL-kommando eller kopiera den aktuella begäran tillbaka som cURL. Föredras ett steg-för-steg-bygge av återanvändbara begäranden? Använd HTTP-förfrågningsbyggaren. Se även familjen API-verktyg.
Allt körs lokalt i webbläsaren. Förfrågningar över ursprungsgränser omfattas av målserverns CORS-policy — se noten nedan om en begäran misslyckas.
Frågeparametrar
Huvuden
Body
Authorization
Alternativ
När det fylls i läggs begärans URL till detta prefix. Användbart för servrar som blockeras av CORS.
200
Brödtext Rubriker

                                                                
Varför en begäran kan misslyckas: webbläsare blockerar läsning över ursprungsgränser om inte API:et returnerar Access-Control-Allow-Origin. Om målet inte tillåter CORS kan en egen CORS-proxy köras och dess URL klistras in i proxyprefixet ovan, eller så kan cURL-omvandlaren användas för att köra begäran från en terminal i stället. Begärandekroppar för GET/HEAD ignoreras, och ett WebSocket-verktyg finns separat på WebSocket-testaren.
HTTP-metoder förklarade
Metoden som väljs talar om för servern vad som ska göras med URL:en. Här är vad var och en av de sju verben som detta verktyg kan skicka betyder:
GET — Hämta en resurs: en webbsida, en bild, en lista med poster. “Ge mig det som finns på den här URL:en.” Skrivskyddad och säker att upprepa, och bär normalt ingen begärandekropp (en brödtext i en GET-begäran ignoreras).
POST — Skicka nya data till servern, oftast för att skapa en resurs eller utlösa en åtgärd — skicka in ett formulär, ladda upp en fil, starta ett jobb. Nyttolasten överförs i begärandekroppen. POST är inte idempotent: att skicka samma POST två gånger kan skapa två poster.
PUT — Ersätt hela resursen på URL:en med det som skickas. Kroppen måste innehålla den fullständiga nya versionen av resursen. PUT är idempotent: att upprepa samma begäran ger samma effekt som att skicka den en gång.
PATCH — Ändra endast en del av en resurs. Man skickar bara de fält som ska uppdateras, t.ex. {"email": "new@example.com"}, i stället för hela posten. Välj PATCH när en fullständig PUT skulle tvinga fram att fält som inte ändras skickas om.
DELETE — Tar bort resursen på URL:en. DELETE är idempotent: att ta bort något som redan är borta ger samma resultat (oftast en 404) och gör ingenting två gånger.
HEAD — Precis som GET, men svaret innehåller endast rubriker — ingen brödtext skickas tillbaka alls. Använd HEAD för att kontrollera om en URL finns, hur stor en fil är (Content-Length), när den senast ändrades (Last-Modified) eller vilken typ den är (Content-Type), utan att ladda ned hela innehållet.
OPTIONS — Fråga servern vilka metoder och alternativ som tillåts för en URL, eller utlös en CORS-förkontroll. Svarsrubrikerna, såsom Access-Control-Allow-Methods, listar vad som är tillåtet. OPTIONS bär vanligtvis ingen brödtext; webbläsare skickar det ofta automatiskt före en POST/PUT/PATCH/DELETE över ursprungsgränser.
Lätt att blanda ihop: HEAD kontra GET — begäran är identisk, men HEAD returnerar ingen brödtext. PUT kontra PATCH — PUT ersätter hela resursen; PATCH tillämpar en partiell uppdatering av endast de fält som skickas.