HTTP 메서드

Ouroboros·2023년 8월 25일

네트워크

목록 보기

1/20

0. HTTP

HyperText Transfer Protocol
⑴리소스들을 가져올 수 있도록 해주는 프로토콜
HTTP의 확장성 덕분에, HTTP는 하이퍼텍스트 문서 뿐만 아니라 이미지와 비디오 혹은 HTML 폼 결과와 같은 내용을 가져올 수 있다.
클라이언트-서버 프로토콜
클라이언트(브라우저)의 개별적인 요청들은 서버로 보내지며, 서버는 요청을 처리하고 response라고 불리는 응답을 제공한다.

1. HTTP의 속성

HTTP 메소드	안전	멱등	캐시가능	요청에 Body 있음	응답 Body 있음
GET	예👌	예👌	예👌	놉❌	예👌
POST	놉❌	놉❌	예👌	예👌	예👌
PUT	놉❌	예👌	놉❌	예👌	예👌
PATCH	놉❌	놉❌	예👌	예👌	예👌
DELETE	놉❌	예👌	놉❌	놉❌	예👌
HEAD	예👌	예👌	예👌	놉❌	놉❌
CONNECT	놉❌	놉❌	놉❌	예👌	예👌
OPTIONS	예👌	예👌	놉❌	선택🎶	예👌
TRACE	예👌	예👌	놉❌	놉❌	예👌

1) 안전 (Safe Methods)

계속해서 메소드를 호출해도 리소스를 변경하지 않는 것을 뜻한다.
즉 데이터 변경이 일어나지 않는다.

Method 예시)
데이터를 가져오는 GET 메서드로 예를 들면, 조회를 여러 번 진행해도 데이터는 변하지 않는다.
따라서 GET 방식은 '안전'한 속성을 가지고 있다.

2) 멱등 (Idempotent Methods)

어떤 대상에 같은 연산을 여러 번 적용해도(계속해서 메소드를 호출해도) 결과가 똑같을 때 멱등한다고 한다.
ex)
X*1과 같은 함수는 변수에 1번을 적용해도 1000번을 적용해도 결과값은 똑같다. 이럴 때는 멱등성이 보장된다고 말한다.
하지만 X-1와 같은 함수라면 함수가 한번 호출될 때마다 결과가 달라진다. 이런 연산은 멱등성을 보장하지 않는 것을 뜻한다.

Method 예시)
GET 메소드는 단지 리소스를 읽어 오는 행위를 의미하기에 메소드를 여러번 수행해도 결과가 변경되지 않는다. 마찬가지로 요청에 담긴 리소스로 기존 리소스를 그대로 대체해버리는 PUT 메소드도 여러번 메소드를 수행해도 요청에 담긴 리소스가 변하지 않는 이상 연산 결과가 동일하다.
POST 메소드는 요청시마다 리소스를 새롭게 생성하기 때문에 여러번 메소드를 수행하게 되면 매번 새로운 리소스가 생성된 것이고, 연산을 수행한 결과가 매번 달라진다.

3) 캐시 가능 (Cacheable Methods)

캐싱을 해서 데이터를 효율적으로 가져올 수 있다는 뜻이다. GET, HEAD, POST, PATCH가 캐시가 가능하지만 실제로는 GET과 HEAD만 주로 캐싱에 쓰인다.

4,5) 요청/성공 데이터가 본문(Body) 존재

HTTP Request/response Message는 공백(blank line)을 제외하고 3가지 부분으로 나누어진다.

Start Line
-시작라인
-Request : HTTP method / Request target / HTTP version (3가지)
Response : HTTP version / Status Code / Status Text (3가지) 정보를 담고 있음
Headers
-추가 정보(addtional information)를 담고 있는 부분
-예를 들어, request 메세지 body의 총 길이 (Content-Length) -> Key:Value 형태로 구성
- Body
-HTTP Request가 전송하는 데이터를 담고 있는 부분
-전송하는 데이터가 없다면 body 부분은 비어있음
post 요청일 경우, HTML 폼 데이터가 포함

2. HTTP 메서드 정리 (9가지)

<주요 메소드 5가지>

GET

리소스를 조회
query(쿼리 파라미터)를 통해서 서버에 데이터를 전달

GET /search?q=hm&nuri=ko HTTP/1.1
Host: www.google.com

search : 리소스
q=hm&nuri=ko : 쿼리 파라미터
q : key / hm : value / nuri : 추가적인 데이터
&로 추가적인 데이터를 잇는다
쿼리 파라미터로 데이터를 전송하면 url에 데이터가 그대로 노출되기 때문에 보안에 취약하다.
따라서 get 방식에서 쿼리파라미터로 데이터를 보낼 땐 보안에 민감하지 않는 내용을 포함시킨다.

POST

요청 데이터 처리
주로 데이터 등록, 프로세스 처리에 사용

POST /members HTTP/1.1
Content-Type: application/json
  
{
 "username": "nuri",
 "age": 10
}

위 코드의 공백 아래가 Message body인데, POST 방식은 Message body에 데이터를 담아 전송
ex) 신규 주문 생성 / 새로운 회원 추가 / 게시판 글 올리기 / 양식 전송 결과 등 데이터 블록을 데이터 처리 프로세스에 보내기

PUT

리소스 완전히 대체
해당 리소스가 없으면 새로 생성
파일 붙여넣을 때의 덮어쓰기 같은 개념
어떤 데이터를 덮어쓸지 알아야 요청을 보낼 수 있기 때문에 클라이언트가 리소스의 경로를 알고 url을 지정
cf) POST 방식은 클라이언트가 리소스의 경로를 모른다!

PUT /members/100 HTTP/1.1
Content-Type: application/json

{
 "username": "nuri",
 "age": 10
}

Message body를 통해서 서버로 요청 데이터 전달
member/100이라는 경로의 데이터를 서버는 요청한 데이터로 완전히 대체하거나 새로 등록

PATCH

리소스를 부분적으로 대체하는 메소드

PATCH /members/100 HTTP/1.1
Content-Type: application/json 

{
 "age": 50 
}

Message body를 통해서 서버로 요청 데이터 전달
cf) PUT은 지정한 데이터를 전부 수정하는 메소드지만,
PATCH는 정보의 일부분이 변경되는 방법
ex) 서버에 members/100 리소스에 "username" : "nuri", "age" : 10 이라는 데이터가 저장되어있다고 가정하면,
PUT 방식) "age" : "50"만 남게된다. <-username 필드는 사라짐
PATCH 방식) "username" : "nuri", "age" : "50" <-age 필드 값만 변경

DELETE

리소스를 삭제

DELETE /members/1004 HTTP/1.1
Host: localhost:8080

/members/1004경로의 리소스가 삭제됌

<기타 메소드 4가지>

HEAD:

GET과 동일하지만 메시지 부분을 제외하고, 상태 줄과 헤더만 반환

OPTIONS:

목표 리소스에 대한 통신 가능 옵션을 설명하기 위해서 사용(주로 CORS에서 사용)

CONNECT:

요청한 리소스에 관하여 양방향 연결하는 방식, 터널을 열기 위해서 사용

TRACE:

대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행

👀 비교 정리>_<

GET 🆚 POST
*보안 측면
POST 방식은 URL에 데이터의 정보가 들어 있지 않으므로 GET 방식과 비교했을 때 조금 더 안전하다고 볼 수 있다.

*속도 측면
방식은 캐싱을 한다. 따라서 여러번 요청이 올 때, 저장된 데이터를 활용하므로 GET 방식이 POST 방식에 비해 조금 더 빠를 수 있다.
POST 🆚 PUT
POST 방식은 요청시마다 새로운 데이터를 생성하지만,
PUT 방식은 사용자가 데이터를 지정하고 수정하는 것이기 때문에 같은 요청을 계속하더라도 새로운 데이터가 생기는 것이 아니다.
PUT 🆚 PATCH
PUT은 지정한 데이터를 전부 수정하는 메소드지만,
PATCH는 정보의 일부분이 변경되는 방법이다.
그래서 PUT은 멱등한 속성이 있지만, PATCH는 멱등하다고 볼 수 없다.