Client / testor pentru REST API

Se compun și se trimit cereri HTTP cu parametri de interogare, antete, corpuri JSON / de formular și autentificare Basic sau Bearer, apoi se inspectează starea, durata și răspunsurile JSON formatate. Se poate importa o comandă cURL existentă sau copia cererea curentă înapoi ca cURL. Pentru cereri reutilizabile, pas cu pas, se folosește Constructorul de cereri HTTP. Mai există și familia Instrumente API.
Totul rulează local, în browser. Cererile cross-origin sunt supuse politicii CORS a serverului țintă — se consultă nota de mai jos dacă o cerere eșuează.
Parametri de interogare
Antete
Corp
Autorizare
Opțiuni
Când este completat, URL-ul cererii se adaugă la acest prefix. Util pentru serverele blocate de CORS.
200
Corp Antete

                                                                
De ce poate eșua o cerere: browserele blochează citirile cross-origin, dacă API-ul nu returnează Access-Control-Allow-Origin. Dacă ținta nu permite CORS, se poate rula un proxy CORS propriu și se lipește URL-ul său în prefixul de proxy de mai sus, sau se folosește Convertorul cURL pentru a rula cererea dintr-un terminal. Corpurile cererilor GET/HEAD sunt ignorate, iar instrumentul WebSocket este separat, la Testorul WebSocket.
Metodele HTTP explicate
Metoda aleasă indică serverului ce se dorește cu URL-ul. Iată ce înseamnă fiecare dintre cele șapte verbe pe care le poate trimite acest instrument:
GET — Se preia o resursă: o pagină web, o imagine, o listă de înregistrări. Se cere ceea ce se află la acest URL. Doar citire și sigură la repetare; de obicei nu are corp de cerere (un corp la o cerere GET, dacă există, este ignorat).
POST — Se trimit date noi către server, de obicei pentru a crea o resursă sau a declanșa o acțiune — trimiterea unui formular, încărcarea unui fișier, pornirea unei sarcini. Datele circulă în corpul cererii. POST nu este idempotent: trimiterea aceluiași POST de două ori poate crea două înregistrări.
PUT — Se înlocuiește întreaga resursă de la URL cu ce se trimite. Corpul trebuie să conțină versiunea completă nouă a resursei. PUT este idempotent: repetarea aceleiași cereri are același efect ca trimiterea ei o singură dată.
PATCH — Se modifică doar o parte a unei resurse. Se trimit doar câmpurile care se actualizează, de ex. {"email": "new@example.com"}, în loc de înregistrarea întreagă. Se alege PATCH când un PUT complet ar obliga la retrimiterea câmpurilor neatinse.
DELETE — Se elimină resursa de la URL. DELETE este idempotent: ștergerea unei resurse deja dispărute returnează același rezultat (de obicei un 404) și nu face nimic de două ori.
HEAD — Exact ca GET, dar răspunsul conține doar antete — nu se trimite înapoi niciun corp. Se folosește HEAD pentru a verifica dacă există un URL, cât de mare este un fișier (Content-Length), când a fost modificat ultima oară (Last-Modified) sau ce tip are (Content-Type), fără a descărca întregul conținut.
OPTIONS — Se cere serverului ce metode și opțiuni sunt permise pentru un URL sau se declanșează o verificare preliminară CORS. Antetele de răspuns, precum Access-Control-Allow-Methods, listează ce este permis. OPTIONS de obicei nu are corp; browserele îl trimit adesea automat înaintea cererilor POST/PUT/PATCH/DELETE cross-origin.
Ușor de confundat: HEAD față de GET — cererea este identică, dar HEAD nu returnează corp. PUT față de PATCH — PUT înlocuiește întreaga resursă; PATCH aplică o actualizare parțială doar a câmpurilor trimise.