주요 HTTP 메서드와 상태코드

HTTP 메서드

HTTP 메서드는 클라이언트가 웹 서버에 특정 동작을 요청하기 위해 사용하는 명령어입니다.

1. GET

• 용도: 리소스 조회
• 특징:
  • 서버의 데이터를 변경하지 않는 읽기 전용 요청(멱등성)
  • URL에 파라미터가 노출되므로 민감한 정보 전송에 부적합
  • 캐싱 가능
• 개발 시 주의점:
  • 데이터 변경 작업에 사용하지 않아야 함
  • URL 길이 제한(약 2,048자)을 고려해야 함

2. POST

• 용도: 리소스 생성
• 특징:
  • 요청 본문(body)에 데이터를 포함
  • 멱등성을 보장하지 않음(같은 요청을 여러 번 보내면 여러 리소스가 생성될 수 있음)
  • 캐싱이 기본적으로 되지 않음
• 개발 시 주의점:
  • 멱등성 보장이 필요한 경우 추가 로직 구현 필요
  • 보안 처리(CSRF 방어) 필수

3. PUT

• 용도: 리소스 전체 수정
• 특징:
  • 멱등성 보장(같은 요청을 여러 번 보내도 결과가 같음)
  • 리소스 전체를 대체하는 개념
• 개발 시 주의점:
  • 클라이언트가 모든 필드 값을 알고 있어야 함
  • 누락된 필드는 null 또는 기본값으로 대체될 수 있음

4. PATCH

• 용도: 리소스 부분 수정
• 특징:
  • 리소스의 일부만 업데이트
  • 구현에 따라 멱등성이 보장될 수도 있고 아닐 수도 있음
• 개발 시 주의점:
  • 어떤 필드만 수정할지 명확히 정의해야 함
  • JSON Patch나 JSON Merge Patch 형식 고려

5. DELETE

• 용도: 리소스 삭제
• 특징:
  • 멱등성 보장(한 번 삭제된 리소스를 다시 삭제해도 상태는 동일)
  • 실제 구현에 따라 물리적 삭제 또는 논리적 삭제(soft delete)가 가능
• 개발 시 주의점:
  • 권한 검증 철저히 필요
  • 관련 리소스의 참조 무결성 고려

6. 덜 자주 사용되지만 알아두면 좋은 메서드

OPTIONS

• 용도: 서버가 지원하는 HTTP 메서드 확인
• 특징: CORS 프리플라이트 요청에 사용
• 개발 시 주의점: CORS 설정 시 적절한 응답 헤더 제공 필요

HEAD

• 용도: GET과 동일하지만 응답 본문 없이 헤더만 반환
• 특징: 리소스 메타데이터만 확인할 때 유용

HTTP 상태 코드

상태 코드는 서버가 클라이언트에게 요청 처리 결과를 전달하는 3자리 숫자입니다. 서버 개발자는 적절한 상태 코드를 반환하여 클라이언트에게 명확한 피드백을 제공해야 합니다.

1xx (정보)

• 요청이 수신되어 처리 중임을 나타냄
• 개발자가 직접 사용하는 경우는 드뭄

2xx (성공)

• 200 OK: 요청 성공
• 201 Created: 리소스 생성 성공(POST 요청 후 응답으로 많이 사용)
• 204 No Content: 요청 성공했으나 반환할 콘텐츠가 없음(DELETE 성공 시 자주 사용)

개발 시 주의점:

• 201 응답 시 Location 헤더에 생성된 리소스의 URI 포함하는 것이 좋음
• 비동기 작업의 경우 202 Accepted 고려

3xx (리다이렉션)

• 301 Moved Permanently: 리소스의 URI가 영구적으로 변경됨
• 302 Found: 리소스의 URI가 일시적으로 변경됨
• 304 Not Modified: 캐시된 리소스가 여전히 유효함

개발 시 주의점:

• 리다이렉션 시 Location 헤더에 새 URI 반드시 포함
• API 버전 관리 시 301 상태 코드 활용 가능

4xx (클라이언트 오류)

• 400 Bad Request: 잘못된 요청 구문, 유효하지 않은 요청 메시지
• 401 Unauthorized: 인증 필요, 실제로는 “Unauthenticated(인증되지않음)”의 의미
• 403 Forbidden: 인증은 됐으나 권한 없음
• 404 Not Found: 요청한 리소스를 찾을 수 없음
• 405 Method Not Allowed: 허용되지 않은 HTTP 메서드
• 409 Conflict: 현재 서버 상태와 충돌
• 429 Too Many Requests: 사용자가 지정된 시간에 너무 많은 요청을 보냄

개발 시 주의점:

• 명확한 오류 메시지 제공으로 디버깅 용이하게 함
• 보안을 위해 상세한 내부 오류 정보는 노출하지 않음
• 401과 403의 차이를 명확히 구분해서 사용

5xx (서버 오류)

• 500 Internal Server Error: 서버 내부 오류
• 502 Bad Gateway: 게이트웨이가 잘못된 응답을 수신
• 503 Service Unavailable: 서버가 일시적으로 요청을 처리할 수 없음
• 504 Gateway Timeout: 게이트웨이 제한 시간 초과

개발 시 주의점:

• 프로덕션 환경에서는 상세 오류를 클라이언트에게 노출하지 않음
• 로깅 시스템을 통해 서버 오류 기록 및 모니터링 필요
• 서버 오류는 개발자가 해결해야 할 문제임을 인지

HTTP 상태 코드 설계 원칙

1. 명확성: 상태 코드는 응답의 성격을 명확히 나타내야 함
2. 일관성: 동일한 상황에서는 항상 동일한 상태 코드 반환
3. 간결성: 응답 본문보다는 상태 코드로 결과를 먼저 표현

주의할 점

1. 적절한 메서드 선택:
   • 리소스를 조회만 할 때는 GET
   • 리소스를 생성할 때는 POST
   • 리소스 전체를 업데이트할 때는 PUT
   • 리소스 일부를 업데이트할 때는 PATCH
   • 리소스를 삭제할 때는 DELETE
2. 올바른 상태 코드 반환:
   • 성공 시 적절한 2xx 코드
   • 클라이언트 오류 시 적절한 4xx 코드
   • 서버 오류 시 적절한 5xx 코드
3. 멱등성 고려:
   • GET, PUT, DELETE는 멱등성 보장
   • POST는 멱등성을 보장하지 않음
   • PATCH는 구현에 따라 다름
4. 보안 고려사항:
   • 민감한 데이터는 URL 파라미터로 전송하지 않음
   • CSRF 토큰 사용으로 POST, PUT, DELETE 요청 보호
   • 권한 검증 로직을 철저히 구현