이 사이트의 실습은 자바스크립트를 켜야 움직입니다. 아래는 같은 내용을 글로 적은 것입니다.

기초개념 › 네트워크

HTTP 메서드

GET과 POST는 무엇이 다른가

HTTP 요청의 첫 줄 맨 앞 낱말을 메서드라고 합니다. 메서드는 서버에게 "그 주소에서 무엇을 해 달라"는 요청인지를 알리는 낱말이어서, 같은 /memos 주소라도 GET을 보내는지 POST를 보내는지에 따라 서버가 하는 일이 다릅니다. GET은 서버에 있는 것을 가져오는 메서드로, 서버의 것을 바꿔 달라는 요청이 아닙니다. POST는 요청에 실어 보낸 내용(본문)을 서버가 처리해 달라는 메서드입니다. 서버는 자기가 맡을 메서드를 코드로 만들어 두고, 만들어 두지 않은 메서드로 요청이 오면 405 상태 코드로 답합니다. 이 실습은 메모 목록을 가진 서버에 요청을 보내면서 첫 줄의 메서드를 바꾸고, 같은 요청을 한 번 또는 두 번 보내, 서버의 메모가 어떻게 되는지를 봅니다. 코드 칸의 위쪽은 서버에 실제로 보낸 요청의 글자이고, # 으로 시작하는 줄은 서버에 보내지 않는 설명입니다(서버에 무엇을 만들어 두었는지, 보내는 횟수). 코드 칸은 서버 프로그램의 코드가 아니라 주고받은 것을 적은 것입니다. (빈 줄)은 아무 글자도 없는 줄을 눈에 보이게 적은 것입니다.

실행으로 대조 · Node.js 24.18.0의 http 서버에 요청 글자를 그대로 보내는 여섯 가지 조합을 실행해 대조

이 실습에 나오는 개념

HTTP 메서드

요청이 자원에 대해 수행하려는 동작을 나타낸다. GET은 조회, POST는 생성이나 처리 요청, PUT은 전체 교체, PATCH는 일부 수정, DELETE는 삭제를 뜻한다. 메서드의 의미에 맞게 사용해야 캐시, 재시도 같은 HTTP의 동작이 기대대로 이뤄진다.

GET 메서드

GET은 요청 대상(자원)의 현재 내용을 전달해 달라고 요청하는 HTTP 메서드다(RFC 9110 9.3.1절). GET은 읽기 전용의 의미로 정의된 "안전한" 메서드여서, 클라이언트는 GET을 보내면서 서버의 상태가 바뀌기를 요청하지도 기대하지도 않는다(9.2.1절). 그래서 같은 GET을 여러 번 보내도 서버에 남는 것은 달라지지 않는 것이 보통이다. GET 요청에 본문을 실어 보내도 그 본문에는 일반적으로 정해진 의미가 없다(9.3.1절).

POST 메서드

POST는 요청에 실어 보낸 본문(내용)을 요청 대상이 자기 규칙대로 처리해 달라고 요청하는 HTTP 메서드다(RFC 9110 9.3.3절). 대표적인 쓰임은 HTML 양식에 적은 값을 처리하는 프로그램에 넘기기, 게시판 같은 곳에 글 올리기, 아직 식별되지 않은 새 자원 만들기, 기존 자원의 내용 뒤에 데이터 덧붙이기다. POST는 안전한 메서드도 멱등한 메서드도 아니어서(9.2절), 같은 POST를 두 번 보내면 서버가 두 번 처리할 수 있다. 처리 결과 새 자원이 만들어졌다면 서버는 201 Created 상태 코드와 Location 헤더로 답하도록 권장된다(9.3.3절).

405 Method Not Allowed와 Allow 헤더

405 Method Not Allowed는 요청 줄의 메서드를 서버가 알고 있지만 그 요청 대상은 그 메서드를 지원하지 않는다는 뜻의 상태 코드다(RFC 9110 15.5.6절). 서버는 405 응답에 Allow 헤더를 반드시 붙여, 그 대상이 현재 지원하는 메서드를 알려 주어야 한다(15.5.6절, 10.2.1절). 예를 들어 Allow: GET, POST는 그 대상이 GET과 POST를 받는다는 뜻이다. 서버가 메서드 자체를 모르거나 구현하지 않았을 때는 405가 아니라 501 Not Implemented로 답하도록 권한다(9.1절).

이렇게 바꿔 보세요

• 처음 설정으로 — 서버가 목록을 돌려주기만 합니다. 서버의 메모는 그대로입니다.
• 같은 GET을 두 번 보내면 — 두 번 보내도 응답이 같고, 서버의 메모는 그대로입니다.
• POST로 바꾸면 — 서버가 본문의 글을 목록에 더해서 메모가 하나 늘어납니다.
• 같은 POST를 두 번 보내면 — 보낼 때마다 메모가 하나씩 늘어납니다.
• DELETE로 바꾸면 — 서버가 만들어 두지 않은 메서드라서 405로 거절합니다.

처음 설정으로 실행하면

1. 클라이언트(요청을 보내는 쪽)가 서버에 아래 글자를 보냅니다. 이 글이 HTTP 요청입니다. 서버에는 처음에 메모 first 하나가 들어 있는 목록이 있습니다. 첫 줄의 맨 앞 낱말이 메서드로, 서버에게 무엇을 해 달라는 요청인지를 나타냅니다. 이 요청의 메서드는 GET입니다. 그 뒤의 /memos는 어느 주소에 대한 요청인지(경로)이고, HTTP/1.1은 어떤 규칙으로 쓴 글인지(버전)입니다.
2. 서버가 글자를 읽기 시작합니다. 첫 줄에서 메서드는 GET, 경로는 /memos임을 읽습니다. 서버는 자기가 만들어 둔 것(코드 칸 아래의 # 서버 줄) 가운데 같은 메서드와 경로가 있는지 찾습니다. GET /memos 요청을 맡는 줄이 있습니다.
3. 서버가 GET /memos 줄에 적힌 일을 합니다. 목록을 읽어 응답에 담을 뿐 목록에는 손대지 않아서, 메모는 1개 그대로입니다. 응답에 담는 글은 "first"입니다.
4. 클라이언트가 응답을 받습니다. 상태는 200 OK이고 본문은 "first"입니다.

실행 결과

• HTTP 메서드는 요청의 첫 줄 맨 앞 낱말로, 같은 /memos 주소라도 메서드에 따라 서버가 하는 일이 다릅니다. GET은 서버에 있는 것을 가져오는 메서드라서, 서버는 목록을 돌려주기만 했고 메모는 1개 그대로입니다.
• 서버는 첫 줄의 메서드와 경로를 읽고, 자기가 만들어 둔 것 가운데 맡는 줄을 찾아 그 일을 합니다. GET /memos 줄은 목록을 돌려주는 일입니다.

코드

GET /memos HTTP/1.1
Host: localhost:8080
(빈 줄)

# 서버: 처음 목록에는 메모 first 하나가 있다
# 서버: GET /memos → 목록을 돌려준다
# 서버: POST /memos → 본문의 글을 목록에 더한다

이 모형의 전제

서버는 Node.js 24.18.0의 http 모듈로 127.0.0.1의 빈 포트에 띄운 것으로, 처음 목록에는 메모 first 하나가 있고, GET /memos에는 목록을 ", "로 이은 글을 본문으로 200 OK를, POST /memos에는 요청 본문의 글을 목록에 더한 뒤 더한 뒤의 목록을 본문으로 200 OK를, /memos에 오는 그 밖의 메서드에는 서버 코드가 Allow: GET, POST 줄을 붙인 405를, 그 밖의 주소에는 404를 돌려줍니다. 코드 칸은 서버 프로그램의 코드가 아니라 주고받은 것을 적은 것이고, # 으로 시작하는 줄은 서버에 보내지 않는 설명입니다. 메서드 세 가지와 보내는 횟수 두 가지, 모두 여섯 가지 조합을 실제로 실행했습니다. 클라이언트는 net 모듈로 코드 칸 위쪽의 요청 글자를 줄 끝 CRLF로 그대로 보내고(두 번 보낼 때는 연결을 새로 맺어 같은 글자를 한 번 더), 서버가 연결을 닫을 때까지 받은 응답의 상태 줄, Allow 줄, 본문을 해석했습니다. 서버가 받은 메서드와 경로와 본문, 요청 뒤 서버의 메모 개수와 목록이 바뀌었는지, 마지막에 GET /memos를 한 번 더 보내 읽은 목록이 서버의 실제 목록과 같은지, 없는 주소 /nothing에 GET을 보내면 404가 오는지를 확인해 모형과 대조했고, 화면의 코드가 실행한 요청 글자와 같은 글자인지도 조합마다 확인했습니다. 모두 모형과 일치했습니다. 화면의 Host: localhost:8080은 예시이고, 실제로는 빈 포트에 보냈으며 이 서버는 Host의 값을 따지지 않습니다. GET이 서버의 것을 바꾸지 않은 것은 이 서버를 그렇게 만들었기 때문입니다. 표준은 GET에 읽기 전용의 의미를 정해 두었을 뿐이어서, GET에서 서버의 것을 바꾸는 서버가 어떻게 되는지는 실행해 보지 않았습니다. POST에 200 OK로 답한 것도 이 서버의 선택입니다. 표준은 새 자원이 만들어졌으면 201 Created와 Location 줄로 답하라고 권하는데(9.3.3절), 이 서버의 메모에는 따로 주소가 없어 쓰지 않았습니다. 문서로 확인한 것은 RFC 9110의 9.1절(메서드 이름은 대소문자를 구분하고, 서버가 알지 못하거나 구현하지 않은 메서드에는 501을, 알지만 그 자원이 받지 않는 메서드에는 405를 쓰도록 권한다), 9.2.1절(안전한 메서드: 읽기 전용 의미로 정의되어 클라이언트가 서버의 상태 변화를 요청하지도 기대하지도 않는다), 9.2.2절(멱등), 9.3.1절(GET: 대상 자원의 현재 표현을 전달해 달라는 요청), 9.3.3절(POST: 요청에 실린 표현을 대상 자원이 처리해 달라는 요청과 그 쓰임), 10.2.1절(Allow), 15.5.6절(405 Method Not Allowed: 알지만 대상 자원이 지원하지 않는 메서드, 405 응답에는 Allow를 반드시 붙인다)입니다. 이 문서들은 WebFetch로 열었으나 긴 문서를 구간으로 나누어 열었고 돌아온 것이 요약과 짧은 발췌여서, 문장 전체를 원문으로 대조하지는 못했습니다. 이 실습이 다루지 않는 것: PUT, PATCH, DELETE가 성공하는 경우, 같은 요청을 여러 번 보내도 결과가 같은 성질(멱등)과 응답을 못 받았을 때 다시 보내도 되는지는 "세부 동작 실습: 재시도와 멱등성"에서, 요청과 응답의 글자 모양과 상태 코드 전체는 "세부 동작 실습: HTTP 메시지와 상태 코드"에서, 스프링에서 메서드와 주소로 요청을 가르는 것은 "세부 동작 실습: 요청 매핑과 파라미터 바인딩"에서 다룹니다. 브라우저는 쓰지 않았고, 브라우저 주소창에 주소를 입력하면 GET이 가고 HTML 양식은 POST를 쓸 수 있다는 것은 확인하지 않았습니다.

앞 실습: HTTP 요청 · 다음 실습: HTTP 응답