[HTTP] 개요 및 문서 구조

이지연·2026년 1월 14일

네트워크

목록 보기
2/6
post-thumbnail

요청하신 내용(들여쓰기, 불렛/번호 규칙, 인용/보충 표기 방식)을 일관된 스타일로 맞춰 전체 문서를 정리해드릴게요. 아래 버전은 “큰 단원=H1/H2, 하위는 번호 목록(1., 1-1.), 나열은 - 불렛, 보충은 > 보충: 인용” 규칙으로 통일했습니다.

HTTP 개요

HTTP(하이퍼텍스트 전송 프로토콜, Hypertext Transfer Protocol)는 웹에서 데이터를 주고받기 위해 사용되는 통신 프로토콜(규약) 중 하나임.

  • HTTP/1.1이 현재 가장 많이 사용되는 버전임.
  • 현대의 웹서비스는 HTTP 기반으로 데이터 전송함.
    • HTML, TEXT, IMAGE, 음성, 영상, 파일, JSON, XML 등

“웹에서 요청(Request)과 응답(Response)을 주고받는 기본 규칙”이 HTTP이다.

HTTP 문서 구조

HTTP는 크게 Request(요청)와 Response(응답)로 이루어져 있음.
둘 다 공통적으로 아래 형태를 가짐.

  • Start line
  • Headers
  • Empty line
  • Body

(이미지 위치)

1. Request(요청) 문서

1-1. Start line 구성

1-1-1. HTTP 메서드

HTTP 메서드란 “이 요청으로 무엇을 하고 싶은지”를 나타내는 규칙임.

  • HTTP 메서드 예시
    • GET(데이터주세요)
    • POST(데이터줄게요)
    • PUT
    • PATCH(데이터수정)
    • DELETE(데이터삭제)
  • Body 내용(데이터)이 있는 메서드는 일반적으로 POST, PUT, PATCH임.

HTTP 메서드 상세 의미는 아래와 같음.

  • GET: 조회
  • POST: 주로 등록에 사용
  • PUT: 기존 자원 대체
  • PATCH: 기존 자원 부분 변경
  • DELETE: 자원 삭제

PUT과 PATCH의 차이

<회원정보를 수정하는 시나리오 상상>
이름, email, 나이 등 기존 데이터를 불러와서 수정을 할 것임. 제출하면 서버에 도착함. 서버에서는 이를 PUT으로 약속할지, PATCH로 약속할지를 정해야 함.

  • 기존 데이터를 전체로 불러와서 수정하는데 일부 데이터를 수정하지 않고 넘기는 경우
    • 수정이 된 필드인지 아닌지 서버에서는 알 수 없음 → DB를 뒤져서 비교해야 함(비효율적임) → 이런 성격에는 PUT이 더 어울림.
  • 이름만 수정하는 UI의 경우
    • 단일 필드를 각각 수정하는 경우는 PATCH가 더 적절함.

보충: 즉, FE(axios)와 서버(Spring 어노테이션) 개발자 사이에서 시나리오에 맞게 협의하면 되는 부분임. (PUT이 조금 더 일반적이긴 함)

1-1-2. HTTP 메서드의 멱등성(idempotent)

같은 호출을 여러 번 하였을 때, 응답받는 결과가 동일하고 데이터상에 변경이 없을 때 멱등하다고 표현함.

  • GET, PUT, DELETE는 멱등함.
  • POST만 멱등이 아님.
  • POST는 멱등하지 않으므로 재시도 시 위험할 수 있음.
    • 예: 이미 결제가 되었지만 다시 시도하여 재결제가 될 수 있음

보충: 멱등성은 특히 네트워크 재시도/중복 클릭/타임아웃 재요청 같은 상황에서 사고를 막는 중요한 개념임.

1-1-3. URL (/) 위치

요청 Start line에는 “어디로 갈지”를 나타내는 URL이 들어감. URL 패턴 종류는 대표적으로 두 가지임.

  • Path variable(경로 변수) 방식: member/info/1
    • URI 경로로 보통 리소스 식별자(id=1)를 표현함.
  • Query parameter(쿼리 파라미터) 방식: member/info?id=1
    • URL-encoded 형식(body 작성 형식)과 유사하게 생긴 구조임.
    • ? 뒤에 검색조건/정렬 등의 정보를 주입함.

일반적인 사용 예시는 아래와 같음.

상황예시 URL
회원정보 조회(id로 조회)member/1
회원정보 조회(검색조건으로 조회) → name=”홍길동”, age=30member?name=hongildong&age=30

보충: 실무에서 “단건 식별(리소스 ID)”는 path variable을 더 자주 쓰고, “검색/필터/정렬”은 query parameter를 더 자주 쓰는 편임.

1-1-4. HTTP 버전 명시

  • 예: HTTP/1.1

1-2. Headers(요청 헤더)

1-2-1. Host

Host 헤더에는 도메인 정보가 포함됨. 사용자가 요청하는 URL에 대한 형식임.

  • 기본 형식
    • http://host:port/path
    • https://host:port/path

http 관련

  • 보통 80 포트임.
  • http를 사용하면서 포트 생략 시 80포트를 의미함.
  • 예: http://localhost/member/create

https 관련

  • https(HTTP Secure)는 http 프로토콜 기반에 보안이 추가된 것임.
  • 보통 443 포트 사용함.
  • https를 사용하면서 포트 생략 시 443포트를 의미함.
  • 예: https://naver.com/member/create

cf) http://localhost:8080/의 의미

  • http 프로토콜을 사용하지만 80포트를 쓰는 것은 아니고, 8080 포트를 쓰는 것임.

보충: 같은 host라도 포트가 다르면 실제로는 다른 서비스(서버 프로세스)로 연결되는 경우가 많음.

1-2-2. Content-Type

Content-Type은 “요청 body에 담긴 데이터가 어떤 형식인지”를 서버에 알려주는 헤더임.

  • 대표 예시
    • application/json
    • application/x-www-form-urlencoded
    • multipart/form-data
    • text/plain

1-3. Empty line

헤더와 바디를 구분하는 빈 줄(Empty line)이 존재함.

1-4. Body(요청 바디)

  • 일반적으로 GET, DELETE 요청은 body가 없음.
    • GET은 데이터를 “요청”하는 성격이므로 body를 잘 쓰지 않음.
  • 주요 데이터 타입은 아래와 같음.
    • application/json
    • application/x-www-form-urlencoded
    • multipart/form-data

보충: GET/DELETE에도 스펙상 body를 “완전히 금지”한다고 보기보단, 실무/표준/프레임워크 호환성 관점에서 “일반적으로 쓰지 않음”으로 이해하면 안전함.

Body 데이터 Content-Type 상세 설명(요청 기준)

1) application/json

{
  "username": "hongildong",
  "email": "hong@naver.com",
  "age": 32
}
  • JSON 형식 데이터를 전송할 때 사용함.
  • POST/PATCH/PUT 등 클라이언트가 서버로 데이터를 전송하는 상황에 사용함.
  • JSON은 중첩 객체, 배열 등 구조화된 데이터 표현이 가능하여 가장 많이 사용됨.

2) application/x-www-form-urlencoded

username=hongildong&email=hong@naver.com&age=32
  • “키=값” 쌍으로 데이터를 조립하고 &로 구분함.
  • 간결하게 urlencoded 방식이라 부름.
  • html의 form 태그로 전송했던 것에서 유래함.
  • POST 등에서 사용 가능하나, 현대적인 HTTP 통신에서는 JSON 방식을 더 선호함.

3) multipart/form-data

email=hong@naver.com&age=32&profileImage:(binary file)
  • 주로 텍스트와 함께 파일(이미지, 동영상) 등을 서버로 전송할 때 사용함.
  • key=value 형태이며 파일은 바이너리 데이터로 변환됨.
  • html의 form 태그를 사용한 데서 유래함.
  • application/json은 순수 텍스트 기반이므로 파일 전송 시 multipart/form-data는 대체 불가임.

4) text/plain

Hello World!!
  • 문자열 텍스트 데이터를 그대로 전송할 때 사용함.
  • 많이 사용되지는 않음.

2. Response(응답)

2-1. Start line 구성

  • HTTP 버전 명시: HTTP/1.1

  • HTTP 상태 코드

    • 200번대: 성공
    • 400번대: 요청 오류
    • 500번대: 서버 내부 오류

  • 상태 메시지: OK 등 편의대로 작성

  • 예: 만약 500을 받으면, FE에서는 사용자에게 그에 맞는 메시지를 출력해줘야 함.

HTTP 상태 코드 상세 설명은 아래 글에서 정리함.

2-2. Headers(응답 헤더)

2-2-1. Content-Type

응답에서도 Content-Type은 다양하게 쓰임.

  • application/json
  • text/plain
  • text/html
  • image/png, video/mp4 등

일반적인 경향은 아래와 같음.

  • GET 요청 응답: JSON이 가장 보편적임.
  • POST 요청 응답: text/plain 같은 간단 문자열을 주는 경우도 있음.
  • MVC 패턴: HTML을 응답하는 구조임.

2-3. Empty line

헤더와 바디 구분을 위한 Empty line이 존재함.

2-4. Body(응답 바디)

  • 주요 데이터 타입은 아래와 같음.
    • JSON
    • text
    • html
  • POST 요청을 보내온다면, “OK”와 같은 정상 처리 여부를 문자열로 응답하는 경우가 있음.

즉, 요청은 보통 JSON을 보내고(POST/PUT/PATCH), 응답은 상황에 따라 JSON/텍스트/HTML/파일 등으로 다양하게 내려갈 수 있음

Body 데이터 Content-Type 상세 설명(응답 기준)

1) application/json

  • 서버에서 조립된 구조화된 JSON 데이터를 응답으로 전달할 때 사용함.
  • 가장 많이 사용함.

2) text/plain

ok
  • 처리 상태에 대한 간단한 응답을 주기 위해 사용함.
  • 일반적으로 POST 요청에서 응답되는 형태로 종종 사용됨.

3) text/html

<!DOCTYPE html>
<html>
  <head>
    <title>welcome</title>
  </head>
  <body>
    <p>Hello, world!</p>
  </body>
</html>
  • 서버에서 HTML 문서를 응답으로 줄 때 사용함.
  • 서버가 직접 HTML 문서를 생성(렌더링)해서 반환할 때 사용함.
  • 최근에는 서버와 클라이언트가 분리된 구조(REST API)가 대부분이므로 사용 빈도는 낮음.

4) image/png, video/mp4 등

  • 서버가 파일(이미지, 영상)을 반환할 때는 해당 파일의 실제 형식에 맞는 Content-Type을 설정함.
  • 이미지/영상은 바이너리 데이터로 변환되어 전송됨.
  • 실무에서는 파일을 직접 내려주기보다, 파일이 저장된 URL을 문자열로 응답하는 것이 더 일반적임.
profile
이지연
Eazy하게
이전 포스트

[HTTP] 네트워크에 대한 이해

다음 포스트

[HTTP] HTTP 상태코드

0개의 댓글