REST API-klient / -tester

Lag og send HTTP-forespørsler med søkeparametere, headere, JSON- eller skjemadata og Basic- eller Bearer-autentisering, og undersøk deretter statuskode, tidsbruk og formaterte JSON-svar. Importer en eksisterende cURL-kommando, eller kopier gjeldende forespørsel tilbake som cURL. For å bygge gjenbrukbare forespørsler steg for steg, bruk HTTP Request Builder. Se også API-verktøyene.
Alt kjøres lokalt i nettleseren. Forespørsler på tvers av domener er underlagt målserverens CORS-policy — se merknaden nedenfor hvis en forespørsel mislykkes.
Spørringsparametere
Headere
Body
Authorization
Alternativer
Når feltet er fylt ut, legges forespørselsadressen til etter dette prefikset. Nyttig for servere som blokkeres av CORS.
200
Body Headers

                                                                
Hvorfor en forespørsel kan mislykkes: nettlesere blokkerer lesing på tvers av domener med mindre API-et returnerer Access-Control-Allow-Origin. Hvis målet ikke tillater CORS, kan en egen CORS-proxy kjøres og adressen limes inn i proxy-prefikset over, eller cURL-konverteringen kan brukes til å kjøre forespørselen fra en terminal i stedet. Forespørselsbrødtekster for GET/HEAD ignoreres, og et WebSocket-verktøy finnes separat på WebSocket-testeren.
HTTP-metodene forklart
Metoden som velges, forteller serveren hva som skal gjøres med adressen. Her er hva hver av de sju verbene dette verktøyet kan sende, betyr:
GET — Hent en ressurs: en nettside, et bilde, en liste over poster. “Gi meg det som ligger på denne adressen.” Skrivebeskyttet og trygt å gjenta, og den har normalt ingen forespørselsdata (en brødtekst i en GET-forespørsel, hvis den finnes, ignoreres).
POST — Send nye data til serveren, vanligvis for å opprette en ressurs eller utløse en handling — sende inn et skjema, laste opp en fil, starte en jobb. Nyttelasten sendes i forespørselens brødtekst. POST er ikke idempotent: å sende samme POST to ganger kan opprette to poster.
PUT — Erstatt hele ressursen på adressen med det som sendes. Brødteksten må inneholde den fullstendige nye versjonen av ressursen. PUT er idempotent: å gjenta samme forespørsel gir samme effekt som å sende den én gang.
PATCH — Endre bare deler av en ressurs. Send bare feltene som skal oppdateres, f.eks. {"email": "new@example.com"}, i stedet for hele posten. Velg PATCH når en fullstendig PUT ville tvinge frem at felt som ikke endres, må sendes på nytt.
DELETE — Fjern ressursen på adressen. DELETE er idempotent: å slette noe som allerede er borte, gir samme resultat (vanligvis en 404) og gjør ingenting to ganger.
HEAD — Akkurat som GET, men svaret inneholder bare headere — ingen brødtekst sendes tilbake i det hele tatt. Bruk HEAD til å sjekke om en adresse finnes, hvor stor en fil er (Content-Length), når den sist ble endret (Last-Modified) eller hvilken type den er (Content-Type), uten å laste ned hele innholdet.
OPTIONS — Spør serveren hvilke metoder og alternativer som er tillatt for en adresse, eller utløs en CORS-preflight-sjekk. Svarheaderne, for eksempel Access-Control-Allow-Methods, viser hva som er tillatt. OPTIONS har vanligvis ingen brødtekst; nettlesere sender den ofte automatisk før en POST/PUT/PATCH/DELETE på tvers av domener.
Lett å forveksle: HEAD vs GET — forespørselen er identisk, men HEAD returnerer ingen brødtekst. PUT vs PATCH — PUT erstatter hele ressursen; PATCH gjør en delvis oppdatering av bare feltene som sendes.