HTTP Method

개념

• 클라이언트와 서버 사이에 이루어지는 요청(Request)과 응답(Response) 데이터를 전송하는 방식
• 서버에 주어진 리소스에 수행하길 원하는 행동
• 서버가 수행해야 할 동작을 지정하는 요청을 보내는 방법

필요성

• 리소스와 동작 분리
• 서버가 수행할 동작을 메소드를 통해 지정하면 URI는 리소스만 식별하면 되기 때문

주요 메소드

• GET: 리소스 조회
• POST: 요청 데이터 처리, 주로 등록에 사용
• PUT: 리소스를 대체(덮어쓰기), 해당 리소스가 없으면 생성
• PATCH: 리소스 부분 변경 (PUT이 전체 변경, PATCH는 일부 변경)
• DELETE: 리소스 삭제

참고 기타 메소드

• HEAD: GET과 동일하지만 메시지 부분(body)를 제외하고, 상태줄과 헤더만 반환
• OPTIONS: 대상 리소스에 대한 통신 가능 옵션(메서드)을 설명 (주로 CORS에서 사용)
• CONNECT: 대상 자원으로 식별되는 서버에 대한 터널을 설정
• TRACE: 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행

GET 메서드

특징

• 리소스를 조회할 때 사용하며, 서버에 전달하고 싶은 데이터 쿼리를 통해서 전달
• 메시지 바디를 사용해서 데이터를 전달할 수는 있지만 지원하는 곳이 많지 않아 권장하지 않음
• URL 입력, 링크 클릭하는 경우
• 서버에 데이터를 전달하는 경우, 쿼리스트링을 통해 전달
  • ? key1=value1

POST 메서드

특징

• 데이터 요청을 처리하고, 메시지 바디를 통해 서버로 데이터를 전달
• 주로 신규 리소스를 등록하거나 프로세스 처리에 사용

PATCH 메서드

특징

• 리소스 수정, 부분 변경
• patch를 지원하지 않는 경우 post 사용

PUT 메서드

특징

• 리소스가 있으면 대체하고, 리소스가 없으면 생성한다
• 데이터를 덮어쓴다

DELETE 메서드

특징

• 리소스를 제거할 때 사용한다

특징

• 안전: 계속해서 메소드를 호출해도 리소스를 변경하지 않는다
  • GET
• 멱등: 메소드를 계속 호출해도 결과가 똑같다
  • GET, PUT, DELETE
• 캐시 가능: 캐싱해서 데이터를 효율적으로 가져올 수 있다.
  • GET, HEAD, POST, PATCH

상태코드

특징

• 클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능
• 100번대 ~ 500번대

1xx (Informational)

• 요청이 수신되어 처리중

2xx (Successful)

• 요청 정상 처리
  • 200 OK : 요청 성공
  • 201 Created : 요청 성공해서 새로운 리소스가 생성됨
  • 202 Accepted : 요청이 접수되었으나 처리가 완료되지 않았음
  • 204 No Content : 서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음

3xx (Redirection)

• 요청을 완료하려면 추가 행동이 필요
• Redirection: location 헤더가 있으면 location 위치로 자동 이동
  • 301 Moved Permanently : 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음
  • 302 Found : 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음
  • 303 See Other : 리다이렉트시 요청 메서드가 GET으로 변경
  • 304 Not Modified : 캐시를 목적으로 사용
  • 307 Temporary Redirect : 리다이렉트시 요청 메서드와 본문 유지(요청 메서드를 변경하면 안된다.)
  • 308 Permanent Redirect : 리다이렉트시 요청 메서드와 본문 유지(처음 POST를 보내면 리다이렉트도 POST 유지)

4xx (Client Error)

• 클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할 수 없음
  • 400 Bad Request : 클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없음
  • 401 Unauthorized : 클라이언트가 해당 리소스에 대한 인증이 필요함
  • 403 Forbidden : 서버가 요청을 이해했지만 승인을 거부함
  • 404 Not Found : 요청 리소스를 찾을 수 없음

5xx (Server Error)

• 서버 오류, 서버가 정상 요청을 처리하지 못함
  • 500 Internal Server Error : 서버 문제로 오류 발생, 애매하면 500 오류
  • 503 Service Unavailable : 서비스 이용 불가, 권한 없음

추가

멱등성

• 멱등성은 요청의 효과를 보고 판단
• 서버의 상태는 멱등성이 유지되어야 하는 경우 같은 행위를 여러 번 반복하더라도 같은 효과
• 멱등성이 성립하지 않으면 같은 행위를 여러 번 반복하는 경우 요청마다 다른 효과 발생
• 응답이 다를 수는 있지만, 요청이 의도한 효과를 발휘 > 멱등성 유지

POST방식이 GET방식보다 보안측면에서 더 좋다?

GET과 비교하여 URL에 데이터의 정보가 들어있지 않아 POST가 조금 더 안전하다.

GET방식이 POST방식보다 속도가 빠르다?

GET 방식은 캐싱을 하기 때문에 여러번 요청시 저장된 데이터를 활용하므로 POST 방식 보다 조금 더 빠를 수 있다.

POST vs PUT

POST와 PUT은 구분해서 사용해야한다. POST는 새로운 데이터를 계속 생성하기 때문에 요청시마다 데이터를 생성하지만, PUT은 사용자가 데이터를 지정하고 수정하는 것이기 때문에 같은 요청을 계속하더라도 데이터가 계속 생성되지는 않는다.

PUT vs PATCH

PUT은 지정한 데이터를 전부 수정하는 방식이지만 PATCH는 정보의 일부분이 변경되는 방식이다. 그래서 PUT은 멱등하지만, PATCH는 멱등하다고 볼 수 없습니다.

POST와 PATCH는 왜 멱등성을 보장하지 않는가?

PATCH는 기본적으로 멱등성을 가지지 않지만, PUT과 동일한 방식으로 쓴다면 멱등성을 가질 수 있다, 하지만 추가(append)하는 요청 역시 PATCH를 쓸 수 있어 결과가 매번 달라지는 추가 요청은 멱등성을 가진다고 할 수 없다.

POST는 요청을 보낼 때마다 새로운 데이터를 생성함을 예성함으로써 처음 서버의 상태와 여러 번 요청했을 때의 서버 상태가 다르다.

참고: 블로그1 / 블로그2 / 블로그3 / 블로그4