HTTP 메서드
HTTP 메서드는 클라이언트가 서버에 원하는 작업을 명확하게 전달하고 표준화된 방식으로 리소스를 처리하기 위해 사용됩니다.
사용 이점
리소스와 행위 분리
- HTTP URI는 리소스를 식별하며 HTTP 메서드는 리소스에 대한 행위를 정의합니다.
GET /member/100에서/member/100은 리소스(특정회원),GET은 행위를 의미합니다.
표준화된 통신
- 전세계적으로 표준화된 방식으로 메서드가 정의되어 있어 다양한 시스템간에 쉽게 상호작용이 가능합니다.
HTTP 메서드 종류
GET - 리소스 조회
- 서버에 전달할 데이터를 Query를 사용하여 전달
- 데이터의 길이는 URL길이에 영향을 받아 제한적
- 메시지 바디를 통해 데이터 전달이 가능하지만, 많은 서버에서 허용을 하지 않기 때문에 잘 사용하지 않음.
- 캐싱이 가능함
#데이터 요청
GET /members/100 HTTP/1.1 //[메서드][조회쿼리][HTTP버전]
Host: localhost:8080
#서버 응답처리 - JSON/XML/HTML 등등
{
"username":"kim",
"age": 20
}
#응답 메시지
HTTP/1.1 200 OK // [HTTP버전][응답코드][수신확인]
Content-Type: application/json //[전달타입]
Content-Length: 32 //[길이]
{
"username": "kim",
"age":20
}POST - 요청 처리, 데이터 등록
- 메세지 바디를 통해 서버로 데이터를 전달.
- 서버는 요청 데이터에 대한 처리 기능을 모두 수행
- 전송 데이터 크기 제한이 없음.
- 주로 신규 등록, 프로세스 처리등에 사용
- 캐싱 불가능
- URL에 표시되지 않아 상대적으로 보안성이 높음
POST /login HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
username=user&password=pass123PUT - 덮어쓰기
- PUT은 데이터를 완전히 대체.
- 기존 리소스가 있으면 덮어쓰고, 없는 경우에는 새롭게 생성함.
- PUT은 수정을 목적으로 사용할 수 있지만 전체 대체를 기본으로 하기 때문에 데이터 손실에 주의해야 한다.
기존 리소스 : {name : aaa, age:20}
put 전송 : {age : 10}
변경 리소스 : {age : 10}
과 같은 형태로 완전히 덮어버리기때문에 기존에 있던 name필드가 손실된 것을 확인 할 수 있다.PUT과 POST 비교
PUT
클라이언트가 리소스를 명시적으로 식별. 동일한 요청이 여러번 반복되어도 동일한 결과.POST
서버가 리소스를 식별. 동일한 요청이 반복되면 리소스 중복 생성 가능.
PATCH - 리소스 부분 변경
- PUT에서 일어나는 덮어쓰기를 통한 데이터 손실을 방지하기 위해 생겨난 메서드.
- 데이터 손실을 방지하며, 클라이언트가 수정하려는 필드만 명시할 수 있다.
기존 리소스 : {name : aaa, age:20}
PATCH 전송 : {age : 10}
변경 리소스 : {name : aaa, age : 10} 서버에서 PATCH를 지원하지 않는 경우에는 POST를 통해 부분 업데이트를 구현 할 수 있음
DELETE - 삭제
- 일부 서버에서 DELETE 요청에 메세지 바디를 허용하지 않는 경우에는 쿼리 문자열로 전송해야함.
추가
-
HEAD
- GET과 유사하지만 응답 본문 없이 헤더만 반환되는 메서드.
- 주로 데이터의 존재 여부를 확인 시 사용
-
OPTIONS
- 서버에서 허용하는 메서드와 관련된 정보를 반환
- CORS설정에서 사용
-
TRACE
- 네트워크 경로 테스트에서 사용.
- 보안상 이유로 잘 사용하지 않음.
Method 특징
안전(safe)메서드
- 리소스를 변경하지 않는 메서드
멱등 메서드
- 동일한 요청을 여러번 보내도 서버 상태와 결과가 동일한 메서드
- 서버 상태는 클라이언트 요청 관점에서만 판단(외부 요인 제외)
- GET : 동일한 데이터 조회
- PUT : 대체 작업에도 결과 동일
- DELETE : 다시 삭제 요청해도 상태 동일
캐시 가능
- HTTP 응답이 클라이언트나 프록시 서버에 의해 캐싱될 수 있는 메서드
- 기본적으로 GET, HEAD, 일부 POST는 캐싱 가능
- POST는 캐싱이 가능하지만 구현 어려움이 있어 잘 사용하지 않음.
HTTP 상태 코드
클라이언트와 서버의 통신 상태를 식별할 수 있는 상태코드 입니다.
주로 상위코드에 따라 해석되어 처리되며 상태코드가 추가되더라도 클라이언트는 변경하지 않아도 됩니다.
1xx - Informational : 요청 수신되어 처리 중
- 거의 사용하지 않음.
2xx - Successful : 요청 정상 처리
- 200 OK: 요청 성공
- 201 Created: 요청 성공 및 자원 생성 성공
- 202 Accepted: 요청이 접수만 성공, 처리는 아직
- 204 No Content: 요청은 성공했지만 응답 본문 데이터가 없음
- 예: 웹 문서를 저장한 후 굳이 응답 데이터가 필요하지 않을 때
3xx - Redirection : 추가 행동이 필요
- 웹 브라우저는 3xx 응답의 결과가
Location헤더에 있으면 해당 위치로 자동 이동.
리다이렉션 종류
- 영구 리다이렉션: 특정 리소스의 URI가 영구적으로 이동 (
/member → /user) - 일시 리다이렉션: 일시적인 변경 (예: 주문 성공 후 내역 화면으로 이동)
- 특수 리다이렉션: 결과 대신 캐시를 사용
PRG (POST/Redirect/GET)
- POST 요청 후 중복 요청 문제를 방지하기 위한 방법
- POST 요청 후 서버가 302/303 상태 코드로 리다이렉션 응답
- 클라이언트는 리다이렉션된 URL로 GET 요청을 수행
- 사용 사례:
- 주문 결제 후 결제 내역 확인 페이지 로드
- 회원가입 후 확인 페이지
주요 상태 코드
-
300 Multiple Choices: 여러 리소스 중 선택 가능
-
301 Moved Permanently
- 영구 리다이렉션
- 리다이렉트 시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음
-
302 Found
- 일시적 리다이렉션
- 301과 동일
-
303 See Other
- 302와 동일
- 요청 메서드가 GET으로 변경
-
304 Not Modified
- 캐시를 목적으로 사용
- 응답에 메시지 바디를 포함하지 않으며, 조건부 GET/HEAD 요청 시 사용
-
307 Temporary Redirect
- 302와 동일
- 요청 시 메서드와 본문 유지
-
308 Permanent Redirect
- 영구 리다이렉션
- 301과 동일하지만 요청 메서드와 본문을 유지 (POST 요청 리다이렉션 포함)
4xx - Client error : 클라이언트 오류
- 클라이언트의 요청에 문법적 오류나 잘못된 데이터를 요청하는 경우 발생
주요 상태 코드
-
400 Bad Request
- 요청 구문, 메시지 오류
- API 스펙/파라미터가 잘못된 경우
-
401 Unauthorized
- 인증(Authentication)되지 않음
- 클라이언트가 해당 리소스에 대한 인증 필요
-
403 Forbidden
- 서버가 요청을 이해했지만 승인을 거부
- 인증은 되었으나 권한이 없는 경우 (예: 관리자 페이지 접근 시 일반 사용자 계정)
-
404 Not Found
- 요청 리소스를 찾을 수 없음
- 서버에 요청 리소스가 없는 경우
5xx - Server error : 서버 오류
- 서버 문제로 오류 발생
- 서버에 문제가 있기 때문에 재시도하면 성공할 가능성이 있음
주요 상태 코드
-
500 Internal Server Error
- 서버 내부 문제로 발생
- 애매한 경우 500 오류
-
502 Bad Gateway
- 서버로부터 잘못된 응답을 수신한 경우
- 게이트웨이/프록시 서버에서 오류 발생
-
503 Service Unavailable
- 서버가 일시적 과부하 또는 요청 처리 불가
Retry-After헤더로 복구 시간 예고 가능
-
504 Gateway Timeout
- 서버 요청 시간이 너무 오래 걸림
- 상위 서버로부터 응답 시간 초과로 인해 응답하지 못한 경우
- 응답 자체를 받지 못함
말하는 감자