HTTP Method 종류
HTTP 메서드란 클라이언트와 서버 사이에 이루어지는 요청(Request)과 응답(Response) 데이터를 전송하는 방식을 말한다. 쉽게 말하면 서버에 주어진 리소스에 수행하길 원하는 행동, 서버가 수행해야 할 동작을 지정하여 요청을 보내는 방법이다.
HTTP 메소드의 종류는 총 9가지가 있다. 이 중 주로 쓰이는 메소드는 5가지로 보면 된다.
- 주요 메소드
- GET : 서버에 존재하는 데이터 조회 요청하는 것. CRUD로 따지면 R.
- POST: 서버에 데이터를 처리하는 것을 요청(주로 생성). CRUD로 따지면 C.
- PUT : 리소스를 대체(덮어쓰기), 해당 리소스가 없으면 생성. CRUD로 따지면 C,U
- PATCH : 리소스 부분 변경 (PUT이 전체 변경, PATCH는 일부 변경). CRUD로 따지면 U
- DELETE : 리소스 삭제. 존재하지 않아도 동일하게 동작. CRUD로 따지면 D.
- 기타 메소드
- HEAD : GET과 동일하지만 메시지 부분(body 부분)을 제외하고, 상태 줄과 헤더만 반환
- OPTIONS : 대상 리소스에 대한 통신 가능 옵션(메서드)을 설명(주로 CORS에서 사용)
- CONNECT : 대상 자원으로 식별되는 서버에 대한 터널을 설정
- TRACE : 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행
HTTP 메서드 - GET
- 리소스 조회 메서드 (Read). 클라이언트가 서버에게 정보를 요청할 때 사용하는 method
- GET을 통한 요청은 URL 주소 끝에 key-value 쌍으로 parameter를 포함하여 전송을 하는데, 이 부분을 Query String을 이라고 부른다.
- GET의 주요한 특징중 하나는 캐시가 가능하다는 것이다. 한 번 서버에 GET요청을 한적이 있다면 브라우저가 그 결과를 저장해 둔다. 이후 동일한 요청은 브라우저에 저장된 값으로 가져올 수 있다.
- 쿼리스트링 외에 메시지 바디를 사용해서 데이터를 전달할 수 있지만, 서버에서 따로 구성해야 되기 때문에 지원하지 않는 곳이 많아서 권장하지 않는다.
요청 흐름
정적 데이터 조회 과정
- 이미지, 정적 텍스트 문서 GET
- 쿼리 파라미터 없이 리소스 경로로 단순하게 조회 가능
1. 클라이언트에서 /members/100 으로 100번 멤버를 조회해서 정보를 달라고 GET 요청
2. 서버에서는 요청 메세지를 분석해 내부의 유저정보를 조회한 뒤 결과 Response를 만든다.
3. 서버에서 클라이어트로 응답을 해준다. 그러면 클라이언트에서 정상적으로 받으면 200 OK status를 가지며, 회원정보를 얻게 된다.
- 예시에서는 JSON 형태의 데이터이지만 실제로는 HTML일수도 있고 이미지 같은 멀티미디어 파일일 수도 있고 다양하다.
동적 데이터 조회 과정
- 주로 검색, 게시판 목록에서 검색어로 이용
- 쿼리 파라미터 사용해서 데이터를 전달
- 쿼리 파라미터는 ?key1=value1&key2=value2 구조로 되어 있음
1. 요청 URL 뒤에 ?q=hello&hl=ko 쿼리 파라미터를 줘서 상세한 조회 데이터를 얻는다
HTTP 메서드 - POST
- 전달한 데이터 처리 요청 (주로 생성 Create). 클라이언트가 body를 통해 전달한 데이터를 서버가 처리하도록 요청하는 method
- 서버는 POST 메시지를 받으면 꼭 리소스를 등록하는 것만 아니라, 리소스마다 다양하게 처리한다. 데이터를 생성하거나 변경하기도 하고 특정 프로세스를 처리하기도 한다.
- 메시지 바디(body)를 통해 서버로 요청 데이터 전달하면 서버는 요청 데이터를 처리하여 업데이트
- 예전 HTTP 통신은 POST 요청으로 데이터 삭제, 수정도 form요청으로 같이 수행했다.
- POST 요청은 서버의 상태를 변경시키기 때문에 안정성이 보장되지 않고 멱등성이 유지되지 않는다.
- 만일 데이터를 GET 하는데 있어, JSON으로 조회 데이터를 넘겨야 하는 애매한 경우 POST를 사용
요청 흐름
JSON 데이터 전송 과정
1. 클라이언트는 body에 등록할 회원 정보를 JSON 형태로 만들어 담고 서버로 전송한다.
2. 서버에서는 받은 메세지를 분석해 로직 대로 처리 한다. 예를 들어 데이터베이스에 등록하고 신규 아이디를 생성한다.
3. 신규회원에 대한 데이터를 바디에 담아서 클라이언트로 응답한다.
- 신규 자원 생성은 200이나 201로 응답을 보낸다.
- Location은 자원이 신규로 생성된 URI 경로를 의미한다.
[ Content-Type 헤더 종류 ]
Content-Type: application/x-www-form-urlencoded
- Form의 내용을 HTTP 메시지 바디를 통해서 전송(key=value, 쿼리 파라미터 형식)
- 전송 데이터를 url encoding 처리
- 예) abc김 → abc%EA%B9%80
Content-Type: multipart/form-data
- 파일 업로드 같은 바이너리 데이터 전송 시 사용
- 다른 종류의 여러 파일과 Form의 내용 함께 전송 가능. 그래서 이름이 multipart 이다.
Content-Type: application/json
- TEXT, XML, JSON 데이터 전송 시 사용
HTTP 메서드 - PUT
- 리소스를 대체(수정)하는 메서드 (Update)
- 만일 기존 리소스가 있으면 덮어쓰고, 없으면 새로 생성한다.
- /members/100 데이터가 존재하면 기존에 것을 완전 대체 한다.
- /members/100 데이터가 없으면 대체 할게 없으니까 새로 생성한다.
- 데이터를 대체해야 하니, 클라이언트가 리소스의 구체적인 전체 경로를 지정해 보내주어야 한다.
- POST /members : 멤버 새로 추가
- PUT /members/100 : 100번째 멤버 수정
요청 흐름
PUT 요청에 리소스가 있는 경우
1. 100번 유저의 리소스를 교체하겠다는 요청을 보낸다.
2. 기존에 데이터가 있었다면 완전히 대체된다.
PUT 요청에 리소스가 없는 경우
1. 100번 유저의 리소스를 교체하겠다는 요청을 보낸다.
2. 기존에 데이터가 없다면 POST 와 같이 신규로 생성한다.
PUT 요청에 일부 리소스만 변경하길 원할경우
1. age만 50으로 변경하려고 해당 데이터를 PUT으로 전달한다.
2. 하지만 기존 데이터가 완전히 대체되어 이름 데이터가 삭제된다. (이때는 PATCH 메소드를 이용해야 한다)
HTTP 메서드 - PATCH
- 리소스 일부 부분을 변경하는 메소드 (Update)
- 만일 PATCH를 지원하지 않는 서버에서는 대신에 POST를 사용할 수 있다.
요청 흐름
1. age만 50으로 변경하려고 해당 데이터를 PATCH로 전달한다.
2. PUT과는 다르게 회원 정보에서 age만 변경된다.
HTTP 메서드 - DELETE
- 리소스 제거하는 메소드 (Delete)
- 상태코드는 대부분 200을 사용하고 상황에 따라 204를 사용한다.
요청 흐름
1. 100번째 멤버를 제거하기 위해 DELETE로 전달한다.
2. 서버에서 요청을 받고 데이터베이스의 해당 리소스를 제거 한다.
HTTP 메서드 - OPTION
- 예비 요청(Preflight)에 사용되는 HTTP 메소드
- 예비 요청이란 본 요청을 하기 전에 안전한지 미리 검사하는 것이라고 보면 된다
- 서버의 지원 가능한 HTTP 메서드와 출처를 응답 받아 CORS 정책을 검사하기 위한 요청이다.
HTTP 메서드 특성
안전성(Safe)
- 호출해도 리소스 변경이 일어나지 않는 속성
- 여기서 안전의 기준은 오직 리소스 변경 가능성이며, 외적인 요소는 포함하지 않는다.
- GET, HEAD를 안전한 메소드라고 볼 수 있다. (POST, PUT, PATCH, DELETE는 리소스를 변경하는 메소드이므로)
멱등성(Idempotent)
멱등(idempotent)의 의미는 같은 작업을 계속 반복해도 같은 결과가 나오는 경우를 의미한다. 동일한 자원에 대한 GET요청이라면 클라이언트에 반환되는 모든 응답은 동일해야 한다. 특정 자원에 대한 DELETE의 경우도 자원은 더이상 이용하 수 없어야 하며, DELETE요청을 다시 호출한 경우도 자원은 여전히 사용할 수 없는 상태야여 한다.
- 동일한 요청을 여러 번 보내도 한 번 보내는 것과 같은 것
- 같은 행위를 여러 번 반복하더라도 같은 효과를 받으며, 서버의 상태도 동일하게 남음
- 멱등성은 요청의 결과를 보고 판단
- TimeOut 등으로 클라이언트가 서버로부터 정상 응답을 받지 못 했을 때 같은 요청을 다시 해도 되는지 판단하는 근거
- GET : 몇 번을 조회하더라도 같은 결과가 조회된다. ⇒ 회원 정보를 몇번을 조회한다고 정보가 달라지지 않는다.
- PUT : 결과를 대체한다. 따라서 같은 요청을 여러번해도 최종 결과는 같다.
- DELETE : 결과를 삭제한다. 같은 요청을 여러번 해도 삭제된 결과는 같다.
- POST : 멱등이 아니다. 두 번 호출하면 에러가 발생할수 있다. ⇒ POST로 주문을 두 번 호출하면 결제가 중복될 수 있다.
캐시 가능 (Cacheable)
- 응답 결과를 캐시해 사용할 수 있는 속성이다.
- GET, HEAD, POST, PATCH가 캐시 가능하나, Message Body의 캐시 키의 복잡성 문제로 실제로는 GET, HEAD만 사용
면접
HTTP GET과 POST의 차이
GET 메소드는 클라이언트가 서버에게 리소스를 요청할 때 사용하는 메소드이고, POST 메소드는 서버에게 데이터 처리(주로 생성)를 요청할 때 사용하는 메소드다.
GET 요청의 경우 필요한 정보를 특정하기 위해 URL 뒤에 Query String을 추가하여 정보를 조회하고, POST 요청의 경우 전달할 데이터를 Body 부분에 포함하여 통신한다.
GET 요청의 경우 URL 뒤의 Query String까지 포함해서 브라우저 히스토리에 남게 되고 캐시가 가능하지만, POST 요청의 경우 브라우저 히스토리에 남지 않고 캐시도 불가능하다. 또한 POST 요청은 서버의 상태를 변경시키기 때문에 멱등성이 유지되지 않는다.
HTTP POST과 PUT의 차이
POST는 보통 INSERT의 개념으로 사용되고, PUT은 UPDATE개념으로 생각하면 이해하기 쉽다. 또한 POST는 멱등하지 않고 PUT은 멱등하다. 즉 동일한 자원을 여러번 POST 하면 서버자원에는 변화가 생기지만, 여러번 PUT하는 경우는 변화가 생기지 않는다.
예를들어 POST의 경우 클라이언트가 리소스의 위치를 지정하지 않는 경우 사용된다. (/dogs)
따라서, 아래와 같은 요청이 여러번 수행되는 경우 매번 새로운 dog가 생성되어 dogs/3, dogs/4 등 매번 새로운 자원이 생성된다. 멱등하지 않다는 말이다.
POST /dogs HTTP/1.1
{ "name": "blue", "age": 5 }
HTTP/1.1 201 Created
반면 PUT의 경우는 클라이언트가 명확하게 리소스의 위치를 지정한다. (/dogs/3)
따라서, 아무리 많이 수행되더라도 리소스의 위치가 지정되어 새로운 자원이 생성되지 않으며 동일한 리소스(/dogs/3)를 수정하기 때문에 여러번 요청하더라도 멱등하다.
PUT /dogs/3 HTTP/1.1
{ "name": "blue", "age": 5 }
HTTP PUT과 PATCH의 차이
PUT이 해당 자원의 전체를 교체하는 의미를 지니는 대신, PATCH는 일부를 변경한다는 의미를 지니기 때문에 최근 update 이벤트에서 PUT보다 더 의미적으로 적합하다고 평가받고 있다. 또한 PUT의 경우는 멱등하지만, PATCH의 경우는 멱등하지 않다. PUT은 전체 자원을 업데이트 하기 때문에 동일 자원에 대해서 동일하게 PUT을 처리하는 경우 멱등하게 처리된다. 반면 PATCH로 처리되는 경우 자원의 일부가 변경되기 때문에 멱등성을 보장할 수 없다.
참고