[TIL] HTTP 메서드

HTTP 메서드

---

HTTP 메서드란?

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

• 각각의 메서드는 서로 다른 의미를 구현하지만, 일부 기능은 메서드 집합 간에 서로 공유하기도 함
  • 응답 메서드는 안전하거나, 캐시 가능하거나, 멱등성을 가질 수 있음

1. GET

• GET 메서드는 특정 리소스의 표시를 요청
  • GET을 사용하는 요청은 오직 데이터를 받기만 함.
• 참고로 안정성과 멱등성은 신뢰할 수 없는 네트워크 상의 HTTP를 신뢰할 수 있게 만들어 줌. 만약, GET요청을 하고 응답을 못 받았을 경우 한 번 더 보내더라도 이 동작은 안전.
• 그러므로 GET은 Idempotent 하며 safe
  • 먼저 보낸 요청이 벌써 처리되었다고 하더라도 서버에 다른 영향은 없음

2. HEAD

• HEAD 메서드는 GET 메서드의 요청과 동일한 응답을 요구하지만, 응답 본문을 포함하지 않아 헤더 정보 이외에는 어떤 데이터도 보내지 않음.
• 웹 서버의 다운 여부 점검이나 웹 서버 정보(버전 등)등을 얻기 위해 사용될 수 있음
• 서버는 응답으로 헤더만을 돌려주므로, 리소스를 가져오지 않고도 그에 대해 무엇인가를 알아낼 수 있을 때 사용. 또한 응답의 상태 코드를 통해 개체가 존재하는지 확인할 수 있으며, 헤더만을 확인하여 리소스가 변경되었는지 검사할 수 있음. 추가로, 큰 용량의 리소스를 다운로드할지 말지 결정하기 위해서 사전 요청하는 용도로 사용할 수 있음
• HEAD 역시 Idempotent하며 safe

3. POST

• POST 메서드는 특정 리소스에 엔티티를 제출할 때 쓰임.
  • 종종 서버의 상태의 변화나 부작용을 일으킵니다.
• 서버에 입력 데이터를 전송하기 위해 설계된 메서드
• GET과 POST는 Read와 Create라고 말할 수 있지만, 멱등성에 있어서도 차이점이 있음
• POST는 비멱등성을 갖는다. 같은 POST를 연속적으로 보낸다면 명령은 여러 번 내린 것처럼 부가적인 결과를 가져옴

4. PUT

• PUT 메서드는 목적 리소스 모든 현재 표시를 요청 payload로 바꿈
• POST와 유사한 전송 구조를 가지기 때문에 헤더 이외에 메시지(데이터)가 함께 전송됨. 원격지 서버에 지정한 콘텐츠를 저장하기 위해 사용되며 홈페이지 변조에 많이 악용됨
• PUT 메서드의 의미는 서버가 요청의 본문을 가지고 요청 URL의 이름대로 새 자료를 만들거나, 이미 URL이 존재한다면, 본문을 사용해서 교체하는 것
• 데이터를 변경할 수 있는 메서드이기 때문에 서버 입장에서는 위험할 수 있음
• PUT은 콘텐츠를 변경할 수 있게 해 주기 때문에, 많은 웹 서버가 PUT을 수행하기 전에 사용자에게 비밀번호를 입력해서 로그인을 하도록 요구할 것
• PUT과 POST의 차이점은 PUT은 멱등하다는 것
• POST는 클라이언트가 리소스의 위치를 지정하지 않았을 때 리소스를 생성하기 위해 사용하는 연산이다.
  • 예를 들어, 이 연산을 수행하면, /dogs/2에 생기고, 그 다음번엔 /dogs/3 등 매번 다른 곳에 새로운 리소스가 생성될 수 있으므로, 이 연산은 idempotent 하지 않음
  • 반면, PUT은 리소스의 위치를 명확히 알고 요청을 할 경우 사용함
  • POST /dogs HTTP/1.1 {"name": "blue", "age":5} HTTP/1.1 201 Created
  그렇기 때문에, PUT은 새 리소스를 생성하고, 동일한 내용으로 PUT을 리소스에 요청을 해도 결과는 같게 됨
• 즉, PUT과 POST는 멱등성과 리소스 결정권에 따라 나뉜다고 볼 수 있음. 멱등성을 갖지 않고 리소스를 서버가 결정하면 POST, 멱등성을 가지고 있으며 리소스를 클라이언트가 결정하면 PUT!

5. DELETE

• DELETE 메서드는 특정 리소스를 삭제
• 원격지 웹 서버에 파일을 삭제하기 위해 사용되며 PUT과는 반대 개념의 메서드
• 서버에게 요청 URL로 지정한 리소스를 삭제할 것을 요청. 클라이언트는 삭제가 수행되는 것을 보장하지 못함. HTTP 명세에는 서버가 클라이언트에게 알리지 않고 요청을 무시하는 것을 허용하기 때문
• 보통 대부분의 경우 Idempotent 하면 safe 한데, DELETE는 Idempotent 하지만 리소스를 변경하므로 safe 하지 않음

6. PATCH

• PATCH 메서드는 리소스의 부분만을 수정하는 데 쓰임
  • PUT은 문서 자체의 교체만을 허용하며, 만약 전체가 아닌, 일부만 전달할 경우, 전달한 필드 외 모드 null이나 초기값으로 처리됨
  • 반면, PATCH는 자원의 부분 교체가 가능하며, 수정할 JSON일부를 보낸다고 할 때, 해당 필드만 수정됨
• PUT과 마찬가지로 리소스의 위치를 클라이언트가 알고 있을 때 사용

7. TRACE

• TRACE 메서드는 목적 리소스의 경로를 따라 메시지 loop-back 테스트
• 클라이언트에서 전송한 메시지를 그대로 되돌려주는 에코
• 즉, 요청이 서버에 도달했을 때 어떻게 보이게 되는지 알려줌
  • 클라이언트가 어떤 요청을 할 때, 그 요청은 방화벽, 프락시, 게이트웨이 등의 애플리케이션을 통과할 수 있음
  • 이들에게는 원래의 HTTP 요청을 수정할 수 있는 기회가 있음
  • TRACE는 클라이언트에게 자신의 요청이 서버에 도달했을 때 어떻게 보이게 되는지 알려줌
• 즉, TRACE는 주로 디버깅용으로 사용

8. OPTIONS

• OPTIONS 메서드는 목적 리소스의 통신을 설정
• OPTIONS 메서드는 웹 서버에게 여러 가지 종류의 지원 범위에 대해 물어봄
• 즉, 다른 메서드를 전송하는 방법에 대한 정보를 요청하는 메서드로, 브라우저에서 CORS를 위해서 사용됨
• 서버에게 특정 리소스에 대해 어떤 메서드가 지원되는지 물어볼 수 있음
• 응답메시지 헤더에 Allow 필드를 포함해서 돌려줌

9. CONNECT

• CONNECT 메서드는 목적 리소스로 식별되는 서버로의 터널을 맺음
• 즉, 요청된 리소스와 양방향 통신을 시작
  • 프록시 용도로 사용되는 다른 서버로 연결되ㅏ는 터널을 여는 데 사용할 수 있음

참고 문서

https://developer.mozilla.org/ko/docs/Web/HTTP/Methods