[네트워크] HTTP의 정의와 HTTP 메서드의 속성

 

웹 개발에서 HTTP는 클라이언트와 서버 간 데이터를 주고받는 가장 기본적이고 중요한 프로토콜입니다.

하지만 HTTP 메서드의 속성과 올바른 활용 방안을 충분히 이해하지 못하면, 예상치 못한 오류가 발생할 수 있습니다.

특히, 안전성, 멱등성, 그리고 캐시 가능성과 같은 HTTP 메서드의 속성은 RESTful API 설계와 성능 최적화에서 핵심적인 역할을 합니다.

이 글에서는 HTTP 메서드와 그 속성을 살펴보고, 각 속성을 기반으로 메서드를 어떻게 활용할 수 있는지 정리해보겠습니다.

01 HTTP란

1. HTTP의 정의

HTTP(HyperText Transfer Protocol)는 클라이언트-서버 모델을 기반으로 동작하는 웹 통신 프로토콜입니다.
클라이언트가 요청(Request)을 보내면 서버가 응답(Response)을 반환하는 방식으로 데이터를 주고받습니다.

2. HTTP의 특징

• 클라이언트와 서버가 HTTP 요청 메시지와 HTTP 응답 메시지를 주고 받습니다.
• 주고받을 자원의 특성과 무관하게 자원을 주고받을 수단(인터페이스)의 역할만 수행합니다.
• Stateless, 즉 무상태성을 가져서 서버가 HTTP 요청을 보낸 클라이언트와 관련된 상태를 기억하지 않습니다.
• 지속 연결 프로토콜로 하나의 TCP 연결에서 여러 요청-응답을 주고받을 수 있습니다.

3. HTTP 메서드의 종류

HTTP 메서드는 클라이언트가 서버에 어떤 작업을 요청할지 명시하는 방식입니다.

1. GET: 조회
   • 요청 데이터를 서버에서 읽어 클라이언트로 반환합니다.
   • 주로 데이터를 가져오거나 페이지를 렌더링할 때 사용합니다.
2. POST: 생성 또는 데이터 전송
   • 서버에 데이터를 전송하고 새로운 리소스를 생성합니다.
   • 파일 업로드, 양식 데이터 제출에 자주 사용합니다.
3. PUT: 전체 업데이트
   • 기존 리소스를 대체하거나 새 리소스를 생성합니다.
   • 클라이언트가 리소스의 전체 데이터를 보낼 때 사용합니다.
4. PATCH: 일부 업데이트
   • 리소스의 특정 부분만 수정합니다.
   • PUT보다 효율적이라 자주 쓰입니다.
5. DELETE: 삭제
   • 특정 리소스를 서버에서 삭제합니다.
6. HEAD: 메타데이터 조회
   • GET과 동일하지만, 본문 데이터를 반환하지 않습니다.
7. OPTIONS: 서버가 지원하는 메서드 확인
   • 클라이언트가 특정 리소스에서 사용할 수 있는 메서드를 확인합니다.
8. CONNECT : 양방향 연결
9. TRACE : 루프백 테스트

02 HTTP 메서드의 주요 속성

HTTP 메서드의 속성에는 크게 3가지가 있습니다.

안전성, 멱등성, 캐시 가능성입니다.

각각의 특징과 이 특징이 적용되는 메서드를 정리해보겠습니다.

1. 안전성 (Safe Methods)

안전성은 서버의 상태를 변경하지 않는 요청인지 여부를 의미합니다.

• 특징: 데이터를 조회만 하고, 서버 리소스에 영향을 주지 않습니다.
• 안전한 메서드: GET, HEAD, OPTIONS.

GET /api/users HTTP/1.1

이 요청은 서버에서 사용자의 데이터를 조회만 하며, 서버의 상태는 변하지 않습니다.

2. 멱등성 (Idempotent Methods)

멱등성은 요청을 여러 번 반복 실행해도 결과가 동일한 메서드 속성을 말합니다.

• 특징: 동일한 요청을 반복해도 서버 상태가 동일합니다.
• 멱등한 메서드: GET, PUT, DELETE, HEAD, OPTIONS.

PUT /api/users/1 HTTP/1.1
Content-Type: application/json

{
  "name": "John Doe",
  "email": "john@example.com"
}

이 요청을 여러 번 보내도 결과는 동일하게 유지됩니다.

3. 캐시 가능성 (Cacheable Methods)

캐시 가능성은 요청 결과를 저장해 재사용할 수 있는지 여부를 나타냅니다.

• 특징: 응답 데이터를 캐싱해 네트워크 부담을 감소시킵니다.
• 캐시 가능한 메서드: GET, HEAD (일부 POST).

GET /static/images/logo.png HTTP/1.1

이미지가 자주 요청된다면 클라이언트나 CDN에서 캐싱해 성능을 최적화할 수 있습니다.

4. 총정리

03 올바른 메서드 사용 방안

HTTP 메서드를 안전성, 멱등성, 캐시 가능성이라는 세 가지 속성에 따라 적절히 사용하는 방법을 정리해보겠습니다.

1. 안전성(Safe Methods)을 고려한 사용

안전한 메서드는 서버의 상태를 변경하지 않으므로,

데이터를 조회하거나 상태를 확인하는 작업에 적합합니다.

적용 방안

• GET 메서드를 사용하여 데이터를 조회할 때만 사용해야 합니다.
  • 예: 사용자의 정보를 확인하거나, 상품 목록을 가져오는 작업.
  • 잘못된 사용: 데이터를 변경하거나 삭제 작업에 GET을 사용하는 경우
  • GET /users/delete?id=123 # 권장하지 않음!
• HEAD 메서드를 활용하여 리소스의 존재 여부나 메타데이터만 확인합니다.
  • 예: 이미지 파일의 크기 확인
  • HEAD /images/logo.png HTTP/1.1
• OPTIONS 메서드를 사용해 서버에서 지원하는 메서드나 CORS 설정을 확인합니다.

2. 멱등성(Idempotent Methods)을 고려한 사용

멱등한 메서드는 동일한 요청을 여러 번 반복해도 서버 상태가 동일하게 유지됩니다.

네트워크 장애나 요청 재시도 시에도 일관성을 보장하기 위해 멱등성을 고려해야 합니다.

적용 방안

• PUT 메서드를 사용해 리소스를 수정하거나 새로 생성할 때 멱등성을 유지합니다.
  • 예: 기존 리소스를 완전히 대체하거나 새 리소스를 생성할 때, 동일한 요청을 여러 번 보내도 사용자 정보는 동일하게 유지됩니다.
• DELETE 메서드는 멱등성을 보장해야 하므로, 동일한 요청을 반복해도 리소스가 없어지는 상태는 유지해야 합니다.
  • 예:첫 번째 요청에서 리소스가 삭제되고, 이후 요청은 삭제된 상태를 유지합니다.
• POST는 멱등성을 보장하지 않으므로 중복 생성 방지 로직이 필요합니다.
  1. 클라이언트에서 고유 식별자를 생성
     • 클라이언트가 각 요청에 대해 고유한 UUID를 생성하고 서버에 함께 전달합니다.
     • 서버는 이 UUID를 저장하고, 동일한 UUID가 다시 들어오면 중복 요청으로 간주하여 새 리소스를 생성하지 않습니다.서버 로직:
       • 요청의 key를 데이터베이스나 캐시 시스템에 저장하고, 처리 여부를 확인합니다.
       • 동일한 키로 들어온 요청은 기존 응답을 재사용하거나, 처리하지 않습니다.
  2. 트랜잭션 관리
     • 데이터베이스에서 고유 제약 조건을 설정하여 중복 데이터 삽입을 방지해야 합니다.
       • 예: 이메일에 UNIQUE 조건 추가
       • CREATE TABLE users ( id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(100), email VARCHAR(100) UNIQUE );
       • 서버에서 동일한 이메일로 POST 요청이 들어오면 에러를 반환하거나 무시합니다.
  3. POST와 멱등성을 흉내내기
     • 서버에서 처리 후 동일 요청이 들어올 경우 기존 결과를 반환합니다.
     • 요청 데이터를 검사하여 이미 동일한 리소스가 존재하면 새로 생성하지 않고 기존 리소스를 반환할 수 있습니다.

3. 캐시 가능성(Cacheable Methods)을 고려한 사용

캐시 가능한 메서드는 반복적인 요청을 줄이고 서버의 부하를 감소시키는 데 유용합니다. 데이터의 변경 주기를 고려해 캐싱 전략을 설계해야 합니다.

적용 방안

• GET 요청에 대해 캐시를 적극 활용합니다.
  • 정적 리소스(이미지, CSS, JavaScript 등)는 Cache-Control 헤더를 사용해 브라우저나 CDN에서 캐싱합니다.
  • Cache-Control: max-age=3600
  • 자주 변경되는 리소스(API 응답)는 ETag나 Last-Modified 헤더를 사용해 조건부로 요청을 처리합니다.
  • 서버는 데이터가 변경되지 않은 경우 304 Not Modified를 응답합니다.
  • If-None-Match: "abc123"
• POST 요청은 기본적으로 캐시되지 않지만, 일부 API에서는 결과를 캐싱이 가능합니다.
  • 예: 데이터베이스에서 검색 결과를 반환하는 POST 요청에 대해 캐싱할 수 있습니다.
• 캐시 무효화 고려: 리소스가 변경되었을 경우, 새로운 데이터를 제공하기 위해 캐시를 무효화해야 합니다.
  • 예: PUT 또는 DELETE 요청이 발생한 경우, 관련 GET 요청의 캐시를 삭제.이후 관련 GET 요청 /users/1의 캐시 삭제합니다.
  • PUT /users/1 HTTP/1.1

04 결론

HTTP 메서드의 속성과 역할을 이해하면 RESTful API를 보다 직관적이고 안정적으로 설계할 수 있습니다.

안전성, 멱등성, 캐시 가능성과 같은 속성은 API 설계뿐 아니라

장애 복구, 성능 최적화, 데이터 일관성 유지에도 큰 도움을 줍니다.

실제 개발에서 HTTP 메서드를 올바르게 활용한다면 코드 가독성과 유지보수성이 향상될 뿐 아니라

클라이언트와 서버 간 통신 비용도 줄일 수 있을 것이라 기대합니다.