REST API 클라이언트 / 테스터

쿼리 매개변수, 헤더, JSON/폼 본문, Basic/Bearer 인증으로 HTTP 요청을 작성하고 전송한 뒤 상태, 시간, 예쁘게 출력된 JSON 응답을 살펴보세요. 기존 cURL 명령을 가져오거나 현재 요청을 cURL로 다시 복사하세요. 재사용 요청을 단계별로 만들고 싶다면 HTTP 요청 빌더를 쓰세요. API 도구 family도 참고.
모든 것이 브라우저에서 로컬로 돕니다. 교차 출처 요청은 대상 서버의 CORS 정책을 받습니다 — 요청이 실패하면 아래 참고를 보세요.
쿼리 매개변수
헤더
본문
인증
옵션
채워지면 요청 URL이 이 접두사에 붙습니다. CORS로 차단된 서버에 유용합니다.
200
본문 헤더

                                                                
요청이 실패할 수 있는 이유: API가 Access-Control-Allow-Origin을 돌려주지 않으면 브라우저는 교차 출처 읽기를 차단합니다. 대상이 CORS를 허용하지 않으면 자체 CORS 프록시를 돌리고 그 URL을 위의 프록시 접두사에 붙여넣거나, cURL 변환기로 터미널에서 요청을 실행하세요. GET/HEAD의 요청 본문은 무시되며 WebSocket 도구는 WebSocket 테스터에 따로 있습니다.
HTTP 메서드 설명
고른 메서드가 URL로 무엇을 하길 원하는지 서버에게 말합니다. 이 도구가 보낼 수 있는 일곱 동사 각각의 의미입니다:
GET — 자원 가져오기: 웹 페이지, 이미지, 기록 목록. "이 URL에 있는 것을 주세요." 읽기 전용이고 반복해도 안전하며 보통 요청 본문을 실지 않습니다(GET의 본문은 있어도 무시됩니다).
POST — 새 데이터를 서버로 보냅니다. 보통 자원을 만들거나 동작을 유발하기 위해 — 양식 제출, 파일 업로드, 작업 시작. 페이로드는 요청 본문으로 이동합니다. POST는 멱등이 아닙니다: 같은 POST를 두 번 보내면 기록 두 개가 만들어질 수 있습니다.
PUT — URL의 자원 전체를 보내는 것으로 교체합니다. 본문은 자원의 완전한 새 버전을 실어야 합니다. PUT은 멱등입니다: 같은 요청의 반복은 한 번 보낸 것과 같은 효과입니다.
PATCH — 자원의 일부만 바꿉니다. 전체 기록 대신 업데이트하려는 필드만(예: {"email": "new@example.com"}) 보냅니다. 전체 PUT이 건드리지 않는 필드를 다시 보내게 할 때 PATCH를 고르세요.
DELETE — URL의 자원을 제거합니다. DELETE는 멱등입니다: 이미 없는 것을 삭제하면 같은 결과(보통 404)를 돌려주고 두 번 아무것도 하지 않습니다.
HEAD — GET과 같지만 응답은 헤더만 담고 본문은 전혀 돌려보내지 않습니다. 전체 페이로드를 내려받지 않고 URL이 존재하는지, 파일이 얼마나 큰지(Content-Length), 마지막 수정(Last-Modified), 유형(Content-Type)을 확인하세요.
OPTIONS — 서버에게 URL에 어떤 메서드와 옵션이 허용되는지 묻거나 CORS 사전점검을 유발합니다. Access-Control-Allow-Methods 같은 응답 헤더가 허용된 것을 나열합니다. OPTIONS는 보통 본문이 없고 브라우저는 교차 출처 POST/PUT/PATCH/DELETE 앞에 자동으로 보냅니다.
혼동 쉬운 것: HEAD vs GET — 요청은 동일하지만 HEAD는 본문을 반환하지 않습니다. PUT vs PATCH — PUT은 자원 전체를 교체하고 PATCH는 보낸 필드만 부분 업데이트합니다.