HTTP Method & HTTP Message

wldbs._.·2024년 12월 2일

WEB-STUDY

목록 보기

4/9

HTTP 메서드란? / HTTP Status Code
[WEB] HTTP 메서드란?
HTTP 메서드 종류 & 요청 흐름 💯 총정리
Wikipedia: List of HTTP header fields
[간단정리] HTTP Request/Response 구조
[Network] HTTP의 모든 것 (HTTP특징, URI 설계, 상태코드, 리다이렉션, 헤더)
[Network] HTTP 헤더 정리 및 분석
HTTP 메시지 구조: 요청/응답 메시지
[ETC] HTTP 톺아보기
인프런: 모든 개발자를 위한 HTTP 웹 기본 지식
StackOverflow: Is it considered bad practice to perform HTTP POST without entity body?
StackOverflow: Is an HTTP PUT request required to include a body?
StackOverflow: IAzure API Prefer: return=minimal header
CHATGPT

HTTP 메서드 중, POST/GET/PUT/DELETE 메서드를 알아보자.

1. HTTP 메서드란?

HTTP 메서드란, 클라이언트와 서버 간의 요청(Request)과 응답(Response)을 정의하는 방식이다.

즉, 클라이언트가 웹 서버에게 어떤 종류의 동작을 원하는지를 나타내는 방법이다.
각 메서드는 특정한 종류의 작업을 수행하도록 설계되었다.
8~9가지 종류의 메서드 GET/POST/PUT/DELETE/PATCH/HEAD/OPTIONS/TRACE/CONNECT 가 있으며,
주로 사용되는 4가지 종류의 메서드는 GET/POST/PUT/DELETE이다.

해당 메서드를 사용한 요청이 서버에 영향을 주지 않는 요청 메서드를 안전한 메서드라고 한다.
→ 안전한 메서드는 읽기 전용(서버 데이터에 영향을 주지 않는) 메서드

GET, HEAD, OPTIONS, TRACE 메서드는 → 안전한 메서드
그 외 POST, PUT, DELETE, CONNECT, PATCH 메서드는 서버 데이터를 변경하기 위해 사용되는 메서드 → 안전하지 않은 메서드

멱등 메서드: 여러 번 요청을 보내도 결과가 동일한 메서드
→ GET, PUT, DELETE

2. HTTP 메서드의 종류

각 메서드의 역할과 특징을 간단하게 알아보자.

POST: 새로운 리소스를 생성 요청

요청 본문(Body) 에 데이터를 포함하며, 서버에 새로운 데이터가 저장됨.

GET: 서버에서 데이터를 조회

요청 본문 없이 URL에 필요한 정보 포함, 데이터 변경 없음.

PUT: 기존 데이터를 전체적으로 수정, 해당 리소스가 없으면 생성

요청 본문 에 수정될 데이터를 포함. ← 일부만 수정하려면 PATCH

DELETE: 데이터를 삭제

서버의 특정 리소스를 제거.

그 외

HEAD: GET과 동일하나, HTTP 메시지의 body 부분을 제외하고 조회
PATCH: 리소스 부분 변경(수정)
CONNECT: 대상 자원으로 식별되는 서버에 대한 연결 요청
OPTIONS: 리소스가 지원하는 메서드의 종류 확인 ("Allow"라는 헤더와 함께, 해당 리소스에서 사용 가능한 HTTP 메서드 목록 반환)
TRACE: 웹 브라우저가 보내는 HTTP 요청을 HTTP 응답의 body에 담아 응답, 요청 메시지가 변조되었는지 확인

2-1. POST

POST 메서드는 클라이언트가 서버로 데이터를 전송할 때 사용된다.
주로 새로운 리소스를 생성하거나 서버에 데이터를 제출할 때 활용된다.
POST 요청의 데이터는 요청 본문(Body)에 포함되어 전달된다.

1. 특징

목적: 서버에 데이터를 전송 및 처리
안정성: 서버 상태를 변경할 수 있음(데이터 생성/업데이트)
Idempotent(멱등성): X. 동일한 요청을 여러 번 보내면 중복된 데이터가 생성될 수 있음
- 멱등성: 같은 요청을 여러 번 수행하더라도 결과가 변하지 않는 성질
데이터 전달 위치: URL이 아니라 요청 본문(Body)에 데이터 포함.

2. POST 요청 메시지 예시

POST /users HTTP/1.1
Host: www.example.com
Content-Type: application/json
Content-Length: 52

{
  "name": "Alice",
  "email": "alice@example.com"
}

HTTP 메서드: POST
URL: /users (사용자 데이터를 서버에 전송하여 새로운 사용자 생성 요청)
Host: 서버 도메인 (www.example.com)
Content-Type: 요청 데이터의 형식 (application/json)
Content-Length: 요청 본문의 데이터 크기 (바이트 단위)
본문(Body): JSON 형식의 사용자 데이터

3. POST 응답 메시지 예시

HTTP/1.1 201 Created
Location: /users/123
Content-Type: application/json
Content-Length: 37

{
  "id": 123,
  "name": "Alice",
  "email": "alice@example.com"
}

상태 코드: 201 Created (요청 성공, 새로운 리소스 생성)
Location: 새로 생성된 리소스의 경로(/users/123).
Content-Type: 응답 데이터의 형식 (application/json)
Content-Length: 응답 본문의 데이터 크기
본문(Body): 생성된 사용자 정보

4. POST 요청/응답 흐름
→ 클라이언트가 요청: 새 데이터를 포함하여 서버로 전송.
→ 서버가 처리: 요청 데이터를 읽고, 데이터베이스에 새로운 리소스를 생성. 생성된 리소스를 응답으로 반환.
→ 클라이언트가 응답 수신: 서버에서 반환한 응답 데이터를 확인하고, 새로 생성된 리소스를 활용.

2-2. GET

GET 메서드는 클라이언트가 서버에게 데이터를 요청할 때 사용된다.
주요 웹페이지, 리소스 등을 요청하는 데 쓰이며, 요청 본문(Body) 없이 URL에 필요한 정보를 포함하는 것이 특징이다.

1. 특징

목적: 서버로부터 데이터를 조회
안정성: 서버 데이터에 영향을 주지 않음 (단순 조회 작업)
Idempotent(멱등성): O, 동일한 요청을 여러 번 보내도 결과가 같음
요청 본문 Body: 없음, 필요한 데이터는 URL의 쿼리 파라미터에 포함됨
- 쿼리 파라미터(Query Parameter): URL 끝에 ? 뒤에 키=값 형태로 추가되는 데이터로, 서버에 요청 시 필요한 정보를 전달

2. GET 요청 메시지 예시

GET /users?id=123 HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36
Accept: application/json

HTTP 메서드: GET
URL: /users?id=123 (쿼리 파라미터를 통해 id=123인 유저 정보 요청)
Host: 서버 도메인 (www.example.com)
User-Agent: 요청을 보낸 클라이언트의 정보 (예: 브라우저, OS 등).
Accept: 응답 데이터 포맷 (예: JSON, XML).

3. GET 응답 메시지 예시

HTTP/1.1 200 OK
Date: Sat, 02 Dec 2024 12:00:00 GMT
Content-Type: application/json
Content-Length: 72

{
  "id": 123,
  "name": "Alice",
  "email": "alice@example.com"
}

상태 코드: 200 OK (요청 성공)
Date: 응답이 생성된 시간
Content-Type: 응답 데이터의 타입 (application/json)
Content-Length: 응답 데이터의 크기
본문(Body): JSON 형식으로 유저 정보 반환

4. GET 요청/응답 흐름
→ 클라이언트가 요청: URL에 데이터를 포함하여 서버에 보냄.
→ 서버가 처리: 클라이언트가 요청한 데이터를 서버의 데이터베이스에서 조회, 요청에 맞는 데이터를 찾으면, 이를 응답 본문에 담아 클라이언트에게 반환.
→ 클라이언트가 응답 수신: 서버가 반환한 데이터를 읽어 화면에 표시하거나, 다른 작업에 사용.

2-3. PUT

PUT 메서드는 서버에 데이터를 저장하거나, 기존 데이터를 수정하는 데 사용된다.
클라이언트가 요청한 리소스(예: 특정 URL 경로에 해당하는 데이터)가 이미 존재하면 업데이트, 존재하지 않으면 새로 생성한다.

1. 특징

전체 데이터 업데이트: PUT은 주어진 리소스의 전체 데이터를 대체, 기존 데이터 중 포함되지 않은 값은 제거될 수 있다!
일부 필드만 수정하고 싶다면 PATCH 메서드 사용을 고려
멱등성(Idempotency): O, 동일한 요청을 여러 번 보내도 결과가 변하지 않는다

2. PUT 요청 메시지 예시

PUT /users/123 HTTP/1.1
Host: example.com
Content-Type: application/json
Content-Length: 52

{
  "name": "Alice",
  "email": "alice@example.com"
}

URL: /users/123는 사용자의 고유 ID가 123인 리소스를 의미
Content-Type: application/json은 본문 데이터가 JSON 형식임을 의미
요청 Body: 새로운 사용자 정보를 JSON 형식으로 서버에 전송

3-1. 리소스가 존재하여 업데이트된 경우 PUT 응답 메시지 예시

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 53

{
  "id": 123,
  "name": "Alice",
  "email": "alice@example.com"
}

상태 코드: 200 OK는 요청이 성공적으로 처리되었음을 의미
응답 Body: 업데이트된 리소스를 반환

3-2. 리소스가 없어서 새로 생성된 경우 PUT 응답 메시지 예시

HTTP/1.1 201 Created
Content-Type: application/json
Content-Length: 53
Location: /users/123

{
  "id": 123,
  "name": "Alice",
  "email": "alice@example.com"
}

상태 코드: 201 Created는 새로운 리소스가 성공적으로 생성되었음을 의미
Location 헤더: 새로 생성된 리소스의 URL(/users/123)

2-4. DELETE

DELETE 메서드는 요청에 지정된 특정 리소스를 삭제하는 데 사용된다.
요청 시 삭제할 리소스를 URL로 지정하며, 요청 본문(Body)은 포함되지 않는 경우가 대부분이다. (일반적이지 않지만 가능)

1. 특징

데이터 삭제: 서버에 저장된 특정 리소스 전체를 제거, 리소스 일부만 삭제하는 기능은 제공 X ← 일부 삭제는 PATCH
멱등성(Idempotency): O, 요청을 여러 번 보내도 서버의 상태(리소스 삭제 여부)는 불변
- 리소스가 이미 삭제된 상태라면, DELETE 요청을 다시 보내도 결과 상태는 바뀌지 않는다!
  → 서버는 이미 리소스가 없다는 것을 알리고 적절한 응답(예: 404 Not Found)을 보낼 수 있다.
  → DELETE 요청이 여러 번 실행되어도, 최종적으로 해당 리소스는 없는 상태로 유지
Body 사용: 보통 요청 Body를 포함하지 않지만, 특정 API 설계에서는 예외적으로 추가 데이터를 보낼 수도 있음

2. DELETE 요청 메시지 예시

DELETE /users/123 HTTP/1.1
Host: example.com

HTTP 메서드: DELETE를 사용해 특정 리소스 삭제 요청
URL: /users/123는 삭제하려는 리소스(예: ID가 123인 사용자)를 지정
요청 Body: 보통 비어 있음(필요한 데이터는 URL에서 제공)

3-1. 리소스 삭제 성공의 경우 DELETE 응답 메시지 예시

HTTP/1.1 204 No Content

상태 코드: 204 No Content는 요청이 성공적으로 처리되었고, 응답 본문이 없음을 의미
서버는 리소스를 삭제하고 추가적인 정보 없이 요청을 종료

3-2. 삭제하려는 리소스가 존재하지 않을 경우 DELETE 응답 메시지 예시

HTTP/1.1 404 Not Found
Content-Type: application/json
Content-Length: 35

{
  "error": "User not found"
}

상태 코드: 404 Not Found는 삭제하려는 리소스가 존재하지 않음을 나타냄
응답 Body: 오류 메시지를 JSON 형식으로 반환

3-3. 권한 부족의 경우 DELETE 응답 메시지 예시

HTTP/1.1 403 Forbidden
Content-Type: application/json
Content-Length: 47

{
  "error": "You do not have permission to delete"
}

상태 코드: 403 Forbidden은 클라이언트가 리소스를 삭제할 권한이 없음을 나타냄

DELETE /users 는 모든 데이터를 삭제할 가능성이 있지만, 이는 서버의 구현에 따라 달라진다.
일반적으로:

안전장치가 없는 경우: 모든 사용자 데이터가 삭제될 수 있음.

안전한 구현: 이 요청을 제한하거나 금지. 405 Method Not Allowed

정확한 동작은 서버의 설계 의도에 의존하므로, 명시적인 식별자(id)를 사용하는 것이 권장된다.

3. HTTP 메시지 구조

서버와 클라이언트는 HTTP 메시지를 통해 통신한다.
클라이언트는 서버에 요청 메시지를 보내고, 서버는 클라이언트에게 응답 메시지를 보낸다.

요청이나 응답이냐에 따라 내용은 달라지지만, HTTP 메시지의 구조는 동일하다.
HTTP 메시지는 start-line, header, empty line, message body로 구성되어 있다.

각 줄의 끝은 <CR><LF>로 끝나야 한다. → CR + LF 이 두 동작을 합쳐서 Enter 동작
- 캐리지 리턴(Carriage Return)과 라인 피드(Line Feed) 외에 다른 화이트 스페이스가 포함되면 안된다.
- 캐리지 리턴(줄여서 CR): 현재 위치를 나타내는 커서를 맨 앞으로 이동시킨다
- 라인 피드(줄여서 LF): 커서의 위치를 아랫줄로 이동시킨다는 뜻

1. 시작 라인 (Start Line)

요청(Request): 메서드, URL, HTTP 버전 정보를 포함
응답(Response): HTTP 버전, 상태 코드, 상태 설명을 포함

2. 헤더(Header)

요청/응답과 관련된 추가 정보를 전달
key-value 형식
예: Content-Type, Content-Length, Authorization 등

3. 공백 라인 (Empty Line)

헤더와 본문(Body)을 구분하는 빈 줄
<CR><LF>로만 구성

4. 메시지 바디 (Message Body)

요청(Request): 서버로 전송할 데이터
응답(Response): 클라이언트로 전송할 데이터 (HTML/CSS/JS/이미지 등등)

예시를 살펴보자.

아래는 클라이언트가 JSON 데이터를 서버로 보내는 POST 요청이다.

POST /users HTTP/1.1                    <-- 시작 라인
Host: example.com                       <-- 헤더
Content-Type: application/json
Content-Length: 52
										<-- 공백 라인
{                                        
  "name": "Alice",
  "email": "alice@example.com"
}                                        <-- 메시지 바디

아래는 서버가 요청을 처리한 후 성공을 응답한 것이다.

HTTP/1.1 200 OK                         <-- 시작 라인
Content-Type: application/json           <-- 헤더
Content-Length: 52
										<-- 공백 라인
{                                        
  "id": 123,
  "name": "Alice",
  "email": "alice@example.com"
}                                        <-- 메시지 바디

시작 라인은 요청/응답의 핵심 정보를 담고, 헤더는 부가적인 메타데이터, 메시지 바디는 실제 데이터이다!

4. 서버와 데이터베이스

클라이언트가 서버에 보내는 데이터는 일반적으로 서버의 데이터베이스에 저장된 데이터를 수정하거나 추가하는 작업을 수행한다.

서버의 역할

서버는 클라이언트의 요청을 받아 처리
클라이언트가 요청한 작업(예: 데이터 조회/생성/수정/삭제)에 맞춰 데이터베이스와 상호작용하여 데이터를 가져오거나 수정

클라이언트의 요청

예를 들어, 유저 정보를 수정하고자 할 때 PUT 요청을 보내며, 수정된 정보를 서버로 전송

서버에서의 데이터 처리

서버는 클라이언트의 요청을 처리한 후, 해당 데이터를 데이터베이스에 반영
서버는 요청받은 데이터가 데이터베이스에 이미 존재하는 데이터를 수정하는 것인지, 아니면 새로 생성해야 하는 데이터를 요청하는 것인지를 판별하여 작업을 처리

클라이언트: 서버에 요청을 보냄
서버: 요청을 처리하여 데이터베이스에 변경 사항을 반영
데이터베이스: 실제 데이터를 저장하고 관리하며, 서버가 이 데이터베이스에 데이터 조회/생성/수정/삭제 작업을 수행

5. 포스트맨

아래는 내가 7월쯤에 프로젝트를 진행하며 실행했던 포스트맨의 캡처 화면이다.

5-1. POST

POST: POST 요청을 진행하였으며, 요청 헤더와 바디, 응답 헤더와 바디는 아래와 같다.

요청 헤더에 Content-Type

요청 바디에 JSON 데이터

응답 헤더에 Date, Server, Content-Type, Allow, Content-Length 등등

응답 바디에 JSON 데이터

5-2. GET

GET: GET 요청을 진행하였으며, 요청 헤더와 바디, 응답 헤더와 바디는 아래와 같다.

요청 헤더에 Content-Type

URL의 쿼리 파라미터에 KEY-VALUE

응답 헤더에 Date, Server, Content-Type, Allow, Content-Length 등등

응답 바디에 JSON 데이터

5-3. DELETE

DELETE: DELETE 요청을 진행하였으며, 요청 헤더, 응답 헤더와 바디는 아래와 같다.

요청 헤더에 Content-Type

응답 헤더에 Date, Server, Content-Type, Allow, Content-Length 등등

의문점

body 필수여부

Q. POST, PUT 요청 후 응답에서 body는 필수인가?

A. POST와 PUT 요청에서의 응답(HTTP Response) 본문(Body)은 필수가 아니다.
상황에 따라 본문을 포함하거나 비워둘 수 있다.

→ 이를 위해 클라이언트는 요청 헤더에 Prefer: return=minimal 추가해야 한다!

POST 요청 응답

목적: 새로운 리소스 생성
응답 본문의 사용: 보통 생성된 리소스의 정보를 응답 본문에 포함, 상황에 따라 비워둘 수도 있다.

예시. 응답 본문 포함 → 새로 생성된 리소스의 정보를 반환.

HTTP/1.1 201 Created
Content-Type: application/json

{
  "id": 123,
  "name": "Alice",
  "email": "alice@example.com"
}

예시: 응답 본문 비움 → 생성 성공만을 알리는 상태 코드 반환

HTTP/1.1 201 Created

PUT 요청 응답

목적: 기존 리소스 수정하거나, 지정된 리소스 생성
응답 본문의 사용: 수정된 리소스나 확인 정보를 포함하기도 하지만, 일반적으로는 본문을 비워둘 수 있다.

예시. 응답 본문 포함 → 수정된 리소스의 정보를 반환.

HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 123,
  "name": "Alice Updated",
  "email": "alice@example.com"
}

예시: 응답 본문 비움 → 작업 성공만 알림, 응답 본문은 필요하지 않음

수정 작업의 결과는 보통 클라이언트가 이미 알고 있는 내용

HTTP/1.1 204 No Content

응답 본문 미포함의 경우

POST → 201 Created: 리소스가 새로 생성되었음을 나타냄. 보통 생성된 리소스의 정보를 응답 본문에 포함.

PUT → 204 No Content: 리소스가 성공적으로 수정되었음을 나타냄. 클라이언트는 응답 본문 없이 상태 코드만으로 성공 여부를 알 수 있음.

+) 요청 본문 미포함도 가능