요청과 응답 — HTTP

이 장에서 배우는 것 웹이 실제로 주고받는 것의 모양, 상태 코드 네 개를 구분하는 법, 헤더가 왜 자격증명의 자리인지, 그리고 HTTPS가 정확히 무엇을 지키는지.

왕복 한 번이 전부입니다

브라우저에서 무엇을 하든, 에이전트가 도구를 부르든, 밑에서 벌어지는 일은 같습니다. 요청을 보내고 응답을 받습니다. 그 규칙의 이름이 HTTP입니다.

graph TD
  A["요청<br/>무엇을 · 어디에 · 누가"] --> B["서버"]
  B --> C["응답<br/>상태 코드 + 내용"]

요청의 네 조각

메서드는 넷만 알면 됩니다

아래 세 줄이 승인 지점을 정하는 기준과 같습니다. 읽기만 하는 도구와 쓰는 도구를 나누는 것이 여기서 시작합니다 — 도구는 권한이다가 같은 이야기를 도구 쪽에서 합니다.

응답의 첫 줄 — 상태 코드

세 자리 숫자입니다. 앞자리만 보면 성격이 잡힙니다.

401과 403을 구분하는 것이 실무에서 가장 값어치가 큽니다. 401은 열쇠 문제, 403은 권한 문제라 고치는 사람이 다릅니다. 404가 나오는데 열쇠를 계속 새로 발급하는 것이 가장 흔한 헛수고입니다.

헤더가 신분증 자리인 이유

주소는 브라우저 기록·서버 로그·중간 장비에 그대로 남습니다. 그래서 비밀은 주소에 적지 않고 헤더에 실어 보냅니다.

데이터베이스 붙이기가 연결 문자열을 헤더로 넣게 하는 것도, API 키가 헤더에 실리는 것도 같은 이유입니다. Bearer 는 "이 열쇠를 가진 사람"이라는 뜻의 관용 표기일 뿐입니다.

HTTPS가 지키는 것과 못 지키는 것

주소가 https:// 로 시작하면 오가는 내용이 암호화됩니다. 중간에서 가로채도 못 읽습니다.

"HTTPS라서 안전하다"는 절반만 맞습니다. 전송 구간만 지킵니다. 보낸 곳이 믿을 만한지는 별개 문제이고, 그 판단이 보안 검토가 하는 일입니다.

자주 하는 오해

"500 에러가 나면 제가 뭘 잘못한 건가요"

대개 아닙니다. 500번대는 서버 쪽에서 처리에 실패했다는 뜻입니다. 다만 이상한 값을 보내 서버를 터뜨린 경우도 있으니, 보낸 내용을 한 번은 보세요.

"요청이 실패하면 다시 보내면 되나요"

GET 은 몇 번을 다시 보내도 안전합니다. POST 는 다릅니다 — 응답을 못 받았을 뿐 서버는 이미 만들었을 수 있어 두 번 만들어집니다. REST로 업무 시키기가 이 문제를 따로 다룹니다.

확인

1. 401과 403의 차이는?

2. 비밀 열쇠를 주소가 아니라 헤더에 넣는 이유는?

3. HTTPS가 지켜주지 못하는 것은?

다음은 이 왕복을 사람이 아니라 프로그램끼리 하게 만든 것입니다 → API란 무엇인가