HTTP의 핵심 특성과 데이터를 전송하는 두 가지 방법

웹 통신의 기반이 되는 HTTP(HyperText Transfer Protocol)는 크게 네 가지 주요 특성(요청-응답 기반, 미디어 독립성, 무상태성, 지속 연결)을 갖습니다. 이 글에서는 HTTP가 작동하는 가장 핵심적인 두 가지 원리인 요청-응답 메커니즘과 미디어 독립성, 그리고 이를 바탕으로 클라이언트가 서버로 데이터를 전송하는 방식에 대해 객관적인 사실을 바탕으로 정리합니다.

1. 요청과 응답을 기반으로 동작한다 (Request-Response)

HTTP의 가장 기본적인 전제는 클라이언트의 '요청(Request)'이 전송되지 않으면 서버의 '응답(Response)'도 발생하지 않는다는 것입니다. 요청과 응답은 모두 HTTP 메시지 형태를 띠지만, 각자 고유한 구조를 갖습니다.

HTTP 요청 메시지의 첫 줄인 시작 라인(Start Line) 에는 수행할 작업을 정의하는 HTTP 메서드(Method) 가 반드시 포함되어야 합니다. 메서드는 동일한 대상에 대한 요청이라도 어떤 목적을 가지느냐에 따라 결과를 완전히 바꿔놓습니다. 예를 들어, 사용자 정보를 단순히 읽어오기 위해 설계된 GET 요청을 보내야 할 곳에 실수로 DELETE 요청을 보내면 데이터가 영구히 삭제될 위험이 있습니다. 별도로 메서드를 명시하지 않으면 기본적으로 GET이 사용됩니다.

서버는 클라이언트가 요청한 메서드에 맞춰 작업을 처리한 후, 그 결과를 상태 코드(Status Code) 형태로 응답 메시지의 시작 라인에 담아 반환합니다.

• 200번대 (성공): 200 OK, 201 Created 등 요청이 성공적으로 처리되었음을 나타냅니다.

• 300번대 (리다이렉션): 요청 완료를 위해 클라이언트의 추가 조치가 필요함을 의미합니다.

• 400번대 (클라이언트 오류): 잘못된 문법이나 권한 문제 등 클라이언트 측 원인으로 처리가 불가한 상태입니다.

• 500번대 (서버 오류): 유효한 요청임에도 서버 내부의 문제로 처리에 실패한 상태입니다.

2. 미디어 독립성과 자원의 식별 (URI와 URL)

HTTP는 자신이 전송하는 데이터의 형태나 특성을 제한하지 않는 미디어 독립적인 프로토콜입니다. HTML 문서, JSON 데이터, 이미지(JPEG, PNG), PDF 등 어떠한 종류의 파일도 주고받을 수 있습니다. 이때 데이터의 정확한 유형을 명시하기 위해 Content-Type: text/html 또는 image/png와 같은 MIME(Multipurpose Internet Mail Extensions) 타입을 헤더에 명시하여 독립적인 상호작용을 보장합니다.

HTTP가 다루는 이러한 데이터를 '자원(Resource)'이라고 부르며, 이 자원들은 주로 **URI(Uniform Resource Identifier)**를 통해 식별됩니다. 흔히 URI와 URL(Uniform Resource Locator)을 혼용하지만, 두 개념은 명확한 포함 관계를 갖습니다.

URL이 자원이 위치한 곳을 알려준다면, URI는 특정 자원을 유일하게 식별할 수 있는 정보를 뜻하며 URL을 포괄하는 상위 개념입니다.

• URL의 예시: https://comic.naver.com/webtoon/list (웹툰 목록이 있는 서버 내 위치)

• URI의 예시: https://comic.naver.com/webtoon/list?titleId=784248 (특정 웹툰을 고유하게 식별하는 식별자)

위 예시처럼 URL의 기본 구조(scheme, host, path)에 데이터 식별을 위한 쿼리(query) 스트링이 결합되면 자원의 위치가 매우 명확해지므로, 해당 주소는 완벽한 URI의 역할을 수행하게 됩니다.

3. HTTP 메서드를 활용한 데이터 전송 방식과 멱등성(Idempotency)

클라이언트에서 서버로 데이터를 전달할 때는 크게 URL 쿼리(Query)를 이용하는 방식과 메시지 바디(Body)를 이용하는 방식으로 나뉩니다.

쿼리 파라미터를 이용한 전송 (GET 메서드)

주로 GET 메서드를 사용하여 자원을 조회할 때 사용됩니다. GET 요청 시 메시지 바디를 포함하는 것은 HTTP 명세에 어긋나며, 캐싱 메커니즘이 정상적으로 작동하지 않게 만듭니다. 따라서 데이터 정렬, 필터링, 식별 등은 쿼리 파라미터(?key=value)를 통해 전달하는 것이 올바릅니다.

메시지 바디를 통한 데이터 전송과 멱등성 (Idempotency)

새로운 리소스를 생성하거나 서버의 상태를 변경해야 할 때, 요청 데이터가 URL로 표현하기에 너무 길 때, 또는 민감한 정보를 안전하게 전송해야 할 때는 POST, PUT, PATCH 메서드를 활용하여 메시지 바디에 데이터를 담아 전송합니다.

이러한 메서드를 사용할 때 반드시 이해해야 하는 개념이 **멱등성(Idempotency)**입니다.

• 멱등성의 정의: 첫 번째 수행을 한 뒤 여러 차례 동일한 요청을 반복 적용해도 서버의 상태나 결과가 변경되지 않는 속성을 뜻합니다.

• 사실 관계 정정: 제공해주신 원문에는 "POST, PUT, PATCH 3가지는 모두 멱등성을 지키지 못하는 메서드"라고 작성되어 있으나, 이는 사실이 아닙니다. * PUT: 대상 리소스를 완전히 대체하므로 여러 번 요청해도 결과가 같은 멱등성을 갖는 메서드입니다.

  • POST: 매 요청마다 새로운 리소스를 생성하거나 상태를 변경하므로 멱등성이 없습니다.
  • PATCH: 리소스의 부분 변경을 수행하며 구현 방식에 따라 다르지만 일반적으로 멱등성을 보장하지 않습니다.

서버의 응답과 Location 헤더

POST 메서드를 사용하여 서버에 새로운 리소스 생성을 성공적으로 요청한 경우, 서버는 응답(Response) 헤더의 Location 필드를 활용합니다. 이를 통해 방금 생성된 새로운 자원의 정확한 URI 위치를 클라이언트에게 명확하게 알려줄 수 있습니다.

4. HTML Form을 이용한 데이터 전송 원리와 Content-Type

웹 페이지의 HTML <form> 태그를 통한 데이터 전송 시에는 목적에 따라 메서드와 Content-Type을 다르게 설정해야 합니다.

GET 메서드를 활용한 Form 전송

회원가입이나 상품 주문이 아닌, 정보의 조회 및 공유가 목적일 때는 <form>에서도 GET을 사용합니다.

• 검색어 전송 및 데이터 필터링 (가격 범위, 카테고리 선택)
• 데이터 정렬 (날짜순, 조회수순) 및 페이지네이션
• 현재 상태 북마크 및 공유 (지도 위치, 줌 레벨 등)
• 자주 변경되지 않는 데이터의 캐싱 유도

POST 메서드와 Content-Type의 구분

데이터를 바디에 담아 전송할 때는 전송 데이터의 형식에 따라 두 가지 주요 Content-Type이 사용됩니다.

1. application/x-www-form-urlencoded

• 기본 폼 데이터 전송 방식입니다.
• 폼에 입력된 내용이 key=value 형식으로 구성되며, URL 인코딩 처리를 거쳐 메시지 바디를 통해 전송됩니다. 텍스트 기반의 데이터를 서버로 보낼 때 효율적입니다.

2. multipart/form-data

• 텍스트 데이터뿐만 아니라 이미지, 영상, 파일 등을 함께 전송해야 할 때 사용합니다.
• 메시지 바디가 여러 부분(part)으로 나뉘어 각 데이터가 독립적인 형식으로 전송됩니다.

5. 리소스 관리를 위한 URI 접근 방식 (컬렉션과 스토어)

웹 아키텍처에서 리소스의 URI를 누가 결정하고 관리하느냐에 따라 설계 방식이 달라집니다. 이번에 이야기할 것은 크게 두 가지입니다.

1. 서버가 주도하는 리소스 관리 (예: 회원가입) : 클라이언트가 POST로 회원가입 데이터를 전송하면, 서버가 자체적으로 새로운 식별자(URI)를 생성하고 이를 Location 헤더로 반환합니다. 클라이언트는 사전에 해당 리소스의 URI를 알 수 없습니다.
2. 클라이언트가 주도하는 리소스 관리: 스토어(Store) : 파일 관리 시스템처럼 클라이언트가 파일이나 자원을 업로드할 정확한 리소스의 위치(URI)를 이미 알고 있고, 그 위치에 리소스를 직접 관리하는 방식을 스토어(Store) 라고 명명합니다. 이 경우 클라이언트가 PUT 메서드를 사용하여 특정 URI에 자원을 생성하거나 덮어쓰는 방식으로 시스템이 설계됩니다.