실습용 서버로 요청과 응답을 맞춰 보기

API 주소를 입력해 200이 나오는 것과 필요한 데이터가 정확히 전달되는 것은 별개입니다. 이 글에서는 Postman Echo로 파라미터와 JSON 본문을 되돌려 받아 확인합니다. api.example.com처럼 설명용으로 적은 주소를 실제 작동하는 서버라고 기대하는 혼동을 줄이기 위한 실습입니다.

Echo 서버에는 요청 데이터가 전송됩니다. 실습에는 아래 가상 값만 사용하고 실제 인증 키·고객 정보는 넣지 않습니다. Postman 앱 또는 웹 환경을 준비한 뒤 새 HTTP 요청을 만듭니다. 웹 환경에서 사용하는 에이전트와 네트워크 조건에 따라 전송 방식이 달라질 수 있으며, 기본 흐름은 Postman 시작 문서를 참고할 수 있습니다.

GET: 파라미터가 그대로 돌아오는지 확인

요청 메서드를 GET, 주소를 다음과 같이 설정합니다.

https://postman-echo.com/get

Params에 label = winj-demo, count = 2를 넣습니다. Authorization은 인증 없음으로 두고, URL에 이미 쿼리를 썼다면 Params에서 같은 이름을 중복 추가하지 않았는지 확인합니다.

Send 후 응답에서 다음 부분을 찾습니다. 전체 응답에는 headers와 url 등의 다른 필드도 있습니다.

{
  "args": {
    "label": "winj-demo",
    "count": "2"
  }
}

count가 문자열 "2"인 점이 중요합니다. URL의 쿼리 값은 이 예제에서 숫자 자료형을 선언하지 않습니다. JSON 본문에 숫자 2를 넣는 경우와 구분합니다.

POST: JSON 숫자와 문자열을 구분

새 요청의 메서드를 POST, 주소를 https://postman-echo.com/post로 설정합니다. Body에서 raw·JSON을 선택하고 다음 가상 값을 넣습니다.

{
  "title": "winj-demo",
  "count": 2
}

전송되는 Content-Type이 application/json인지 확인합니다. 응답의 json.title은 winj-demo, json.count는 숫자 2여야 합니다. Echo 응답은 요청을 보여 주는 실습 결과이며 실제 게시글이 사이트에 발행됐다는 뜻은 아닙니다.

상태 코드와 응답 필드를 함께 검사

POST 요청의 Scripts → Post-response에 다음 검사를 넣을 수 있습니다. UI 명칭은 사용하는 버전에 따라 확인합니다.

pm.test("HTTP 200", () => {
  pm.response.to.have.status(200);
});

pm.test("JSON 값과 자료형 유지", () => {
  const body = pm.response.json();
  pm.expect(body.json.title).to.eql("winj-demo");
  pm.expect(body.json.count).to.eql(2);
});

테스트가 실패한다면 무조건 API 전체의 문제로 보지 말고 어떤 조건이 달랐는지 읽습니다. count를 "2"로 바꿔 보내면 숫자 2를 기대하는 두 번째 검사는 실패해야 합니다. 이 차이를 통해 상태 코드만 검사할 때 놓치는 오류를 연습할 수 있습니다. 공식 테스트 예제도 같은 방식으로 참고할 수 있습니다.

GET 실습을 Python으로 옮기기

다음은 추가 패키지 없이 표준 라이브러리를 쓰는 GET 예제입니다. 요청 대기 시간과 문자 해석을 명시하고, 예상한 두 필드를 직접 비교합니다.

import json
from urllib.parse import urlencode
from urllib.request import urlopen

query = urlencode({"label": "winj-demo", "count": 2})
url = "https://postman-echo.com/get?" + query
with urlopen(url, timeout=10) as response:
    data = json.loads(response.read().decode("utf-8"))
if data.get("args") != {"label": "winj-demo", "count": "2"}:
    raise ValueError("예상한 파라미터와 응답이 다릅니다.")
print(data["args"])

실제 운영 코드는 HTTP 오류, 연결 실패, JSON이 아닌 응답도 나누어 처리해야 합니다. 위 예제는 실패를 숨기지 않고 예외로 드러내는 최소 실습이며 자동 재시도나 인증 처리는 포함하지 않습니다.

이번 글 보강 시 Python 예제의 외부 GET은 HTTP 403을 반환해 성공 응답을 실측하지 못했습니다. 위 JSON은 실습에서 기대하는 구조이며, 검증 코드는 가상 응답으로 값·자료형 검사를 확인했습니다. 같은 응답을 받는다면 키를 추가하거나 실제 토큰을 보내지 말고 Postman의 전송 환경·응답 본문을 먼저 확인하세요. Echo 접근이 불가능한 환경에서는 접근 권한이 있는 개발용 API나 모의 서버로 요청 대상을 바꿔 연습할 수 있습니다.

결과가 예상과 다를 때 보는 순서

관찰 확인할 지점
응답 자체가 없음 DNS·프록시·에이전트·시간 초과
HTML 페이지가 옴 최종 URL·리디렉션·로그인/오류 페이지
JSON인데 값이 다름 Params 중복·Body 형식·자료형
인증이 필요한 실제 API에서 실패 문서가 요구하는 인증 위치와 권한
Postman 성공, 웹 화면 실패 브라우저의 CORS·쿠키·출처 조건

응답 시간은 그 요청을 보낸 위치와 네트워크 상태의 측정값입니다. 한 번 빠르게 나왔다고 전체 사용자의 성능을 보장하지 않습니다. 응답 해석 항목은 Postman 응답 문서, 브라우저와의 차이는 CORS 점검 글에서 더 확인할 수 있습니다.

실제 서비스로 옮길 때는 주소·메서드·인증·입력·기대 응답을 한 묶음으로 관리합니다. 공유할 Collection이나 캡처에는 실제 토큰이 포함되지 않았는지 확인하고, 단순히 변수로 바꿨다는 이유만으로 모든 공유 경로에서 비밀이 보호된다고 가정하지 않습니다.