REST API-klient / -tester

Opret og send HTTP-anmodninger med forespørgselsparametre, headers, JSON-/formularkroppe og Basic- eller Bearer-godkendelse, og undersøg derefter status, tidsforbrug og pæn-formaterede JSON-svar. Importér en eksisterende cURL-kommando, eller kopiér den aktuelle anmodning tilbage som cURL. Foretrækkes det at bygge genbrugelige anmodninger trin for trin? Brug HTTP-anmodningsbyggeren. Se også API-værktøjerne.
Alt kører lokalt i browseren. Anmodninger på tværs af domæner er underlagt målserverens CORS-politik — se noten nedenfor, hvis en anmodning mislykkes.
Forespørgselsparametre
Headers
Body
Authorization
Indstillinger
Når det er udfyldt, føjes anmodnings-URL'en til dette præfiks. Nyttigt til servere, der blokeres af CORS.
200
Brødtekst Headere

                                                                
Hvorfor en anmodning kan mislykkes: browsere blokerer læsning på tværs af domæner, medmindre API'et returnerer Access-Control-Allow-Origin. Tillader målet ikke CORS, kan man køre sin egen CORS-proxy og indsætte dens URL i proxy-præfikset ovenfor, eller bruge cURL-konverteren til at køre anmodningen fra en terminal. Anmodningskroppe for GET/HEAD ignoreres, og et WebSocket-værktøj findes separat på WebSocket-testeren.
HTTP-metoder forklaret
Den metode, man vælger, fortæller serveren, hvad der skal ske med URL'en. Her er, hvad hvert af de syv verber, dette værktøj kan sende, betyder:
GET — Hent en ressource: en webside, et billede, en liste over poster. “Giv mig det, der ligger på denne URL.” Skrivebeskyttet og sikkert at gentage, og den bærer normalt ingen anmodningskrop (en krop på en GET-anmodning, hvis der er en, ignoreres).
POST — Send nye data til serveren, normalt for at oprette en ressource eller udløse en handling — indsende en formular, uploade en fil, starte et job. Nyttelasten sendes i anmodningskroppen. POST er ikke idempotent: sendes den samme POST to gange, kan der oprettes to poster.
PUT — Erstat hele ressourcen på URL'en med det, der sendes. Kroppen skal indeholde den komplette nye version af ressourcen. PUT er idempotent: gentagelse af samme anmodning har samme effekt som at sende den én gang.
PATCH — Ændr kun en del af en ressource. Man sender blot de felter, der skal opdateres, fx {"email": "new@example.com"}, i stedet for hele posten. Vælg PATCH, når en fuld PUT ville tvinge én til at gensende felter, man ikke rører ved.
DELETE — Fjern ressourcen på URL'en. DELETE er idempotent: sletning af noget, der allerede er væk, giver samme resultat (normalt en 404) og gør ikke noget to gange.
HEAD — Præcis som GET, men svaret indeholder kun headers — der sendes slet ingen krop tilbage. Brug HEAD til at kontrollere, om en URL findes, hvor stor en fil er (Content-Length), hvornår den sidst blev ændret (Last-Modified), eller hvilken type den er (Content-Type), uden at downloade hele indholdet.
OPTIONS — Spørg serveren, hvilke metoder og indstillinger der er tilladt for en URL, eller udløs en CORS-preflight-kontrol. Svar-headerne, såsom Access-Control-Allow-Methods, lister, hvad der er tilladt. OPTIONS bærer normalt ingen krop; browsere sender det ofte automatisk før en POST/PUT/PATCH/DELETE på tværs af domæner.
Let at blande sammen: HEAD kontra GET — anmodningen er identisk, men HEAD returnerer ingen krop. PUT kontra PATCH — PUT erstatter hele ressourcen; PATCH anvender en delvis opdatering af kun de felter, der sendes.