# 요청과 응답 — HTTP

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

## 왕복 한 번이 전부입니다

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

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

```
요청   GET /api/v1/tasks HTTP/1.1
       Host: localhost:27777
       Authorization: Bearer tt_••••

응답   200 OK
       Content-Type: application/json

       {"tasks": [ … ]}
```

## 요청의 네 조각

| 조각 | 뜻 | 예 |
|---|---|---|
| **메서드** | 무엇을 하려는지 | `GET` `POST` |
| **주소(URL)** | 어디에 | `/api/v1/tasks` |
| **헤더** | 부가 정보 · 신분증 | `Authorization: Bearer …` |
| **본문(body)** | 보낼 내용 | `{"prompt": "…"}` |

### 메서드는 넷만 알면 됩니다

| 메서드 | 하는 일 | 되돌릴 수 있나 |
|---|---|---|
| `GET` | 가져오기 | 안 바꿈 |
| `POST` | 새로 만들기 | **바꿈** |
| `PUT`·`PATCH` | 고치기 | **바꿈** |
| `DELETE` | 지우기 | **못 되돌림** |

**아래 세 줄이 [승인 지점](/guide/ha-guardrails)을 정하는 기준과 같습니다.**
읽기만 하는 도구와 쓰는 도구를 나누는 것이 여기서 시작합니다 —
[도구는 권한이다](/guide/mcp-security)가 같은 이야기를 도구 쪽에서 합니다.

## 응답의 첫 줄 — 상태 코드

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

| 코드 | 뜻 | 무엇을 고쳐야 하나 |
|---|---|---|
| **200** | 됐음 | — |
| **401** | 누구인지 모르겠음 | **열쇠** — 안 보냈거나 틀림 |
| **403** | 누군지는 알지만 권한 없음 | **권한** — 계정에 그 권한을 주기 |
| **404** | 그런 주소 없음 | **주소** — 오타이거나 지워짐 |
| **429** | 너무 자주 부름 | **속도** — 잠시 쉬었다 재시도 |
| **500** | 서버 쪽이 터짐 | **내 잘못이 아님** — 로그는 서버에 |

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

## 헤더가 신분증 자리인 이유

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

```
✓ Authorization: Bearer tt_abc123…      헤더 — 로그에 안 남는 것이 관행
✗ /api/v1/tasks?token=tt_abc123…        주소 — 기록에 그대로 남습니다
```

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

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

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

```
✓ 지킴 — 중간에서 훔쳐보기 · 내용 바꿔치기 · 가짜 서버로 유인
✗ 못 지킴 — 도착한 서버가 그 데이터로 무엇을 하는지
```

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

## 자주 하는 오해

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

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

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

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

---

## 확인

**1. 401과 403의 차이는?**

<details>
<summary>답</summary>

**401은 누구인지 모르겠다(열쇠 문제), 403은 누군지는 알지만 권한이 없다(권한
문제)** 입니다. 고쳐야 할 대상이 다릅니다.
</details>

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

<details>
<summary>답</summary>

**주소는 기록에 그대로 남기 때문**입니다. 브라우저 기록·서버 로그·중간
장비에 남습니다.
</details>

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

<details>
<summary>답</summary>

**도착한 서버가 그 데이터로 무엇을 하는지**입니다. 전송 구간의 암호화일 뿐
상대를 믿어도 된다는 보증이 아닙니다.
</details>

---

다음은 이 왕복을 사람이 아니라 프로그램끼리 하게 만든 것입니다 →
[API란 무엇인가](/guide/it-api)