모든 개발자를 위한 HTTP 웹 기본 지식 - HTTP 메소드

모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의

인프런 김영한 님의 모든 개발자를 위한 HTTP 웹 기본 지식 강의를 수강한 뒤 정리한 글입니다.

 

목차

• 인터넷 네트워크

• URI와 웹 브라우저 요청 흐름

• HTTP 기본

• HTTP 메소드

• HTTP 메소드 활용

• HTTP 상태코드

• HTTP 헤더1(일반헤더)

• HTTP 헤더2 : 캐시와 조건부 요청

 

1. HTTP API 설계

회원정보를 관리하는 HTTP API를 만들어야 할 때 구현해야 할 기능은 다음과같이 정의했다.

 

회원목록조회 : 모든 회원을 리스트로 조회한다.
회원 조회  : 회원 한 명에 대해 회원상세정보를 조회한다.
회원 등록 : 회원정보 등록
회원 수정 : 회원정보 수정
회원 삭제 : 회원정보 삭제

 

URI 설계 결과

기능을 유추할 수 있도록 URI를 설계했을 때 왼쪽과 같이 설계할 수 있다. 그러나 이는 좋은 URI 설계라고는 할 수 없다. URI는 리소스(회원)에 중점을 두고 설계해야하기 때문에 조회/입력/수정/삭제 라는 행위를 배제하고 오른쪽과 같이 회원 자체를 기준으로 잡고 설계되어야한다. 

2. HTTP 메소드

위의 표와같이 리소스를 중심으로 계층형 구조를 가지도록 URI를 설계하게 되면 조회/등록/수정/삭제 의 URI가 모두 동일하기 때문에 URI(자원)에 대한 행위를 HTTP 메소드를 통해 구분해주어야한다.

 

2.1. HTTP 메소드

주요 HTTP 메소드는 GET, POST, PUT, PATCH, DELETE가 있으며 기타 HTTP 메소드로는 HEAD, OPTIONS, CONNECT, TRACE가 존재한다.

 

• GET : 리소스 조회
• POST : 요청데이터 처리, 주로 리소스 신규 등록에 사용
• PUT : 리소스 대체
• PATCH : 리소스 부분변경
• DELETE : 리소스 삭제
• HEAD : GET과 동일하지만 body를 제외한 상태줄, 헤더만 요청
• OPIONS : 대상 리소스에 대한 통신 가능 옵션(메소드)을 설명(주로 CORS에서 사용)
• CONNECT : 대상 자원으로 식별되는 서버에 대한 터널을 설정
• TRACE : 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행

 

2.1.1. GET

리소스를 조회한다. 서버에 전달할 데이터는 쿼리파라미터(=쿼리스트링)을 이용한다. (최근엔 body를 이용해 전달 할 수 있게 되었지만 권장하지 않음) 

 

GET 과정

1. 클라이언트가 리소스와 GET 메소드를 담은 요청메시지를 서버로 전송

2. 요청메시지가 서버에 도착하면 서버는 데이터(JSON 등)를 만들어 응답메시지에 담아 클라이언트에 전송한다.

 

2.1.2. POST

클라이언트가 보내는 데이터를 서버측에서 처리해주기위한 메소드이다. message body를 통해 요청데이터를 전달하며 주로 데이터 신규등록, 프로세스 처리에 사용된다.

 

POST 과정

1. 클라이언트가 리소스와 POST메소드를 담은 요청메시지를 서버로 전송 (이 때 서버-클라이언트 간에 POST로 들어온 자원을 어떻게 처리할지는 미리 약속되어있다.)

2. 신규등록은 수행한다고 가정했을 때 서버에 리소스가 생성되고 신규 리소스 식별자가 생성된다.

3. 서버는 HTTP코드, 자원의 경로, 자원 데이터 등을 담은 응답 데이터를 클라이언트에 전송한다.

 

POST 메소드에서 말하는 요청데이터 처리예시

- HTML 양식에 입력된 필드와 같은 데이터 블록을 데이터 처리 프로세스에 가공

 ex) 회원가입, 주문서작성 시 HTML Form에 데이터 입력

- 게시판 글쓰기, 댓글 달기

- 서버가 식별하지 않은 새 리소스 생성

 ex) 신규 주문 생성

- 기존 자원에 데이터 추가

 ex) 문서 내용 추가

* POST로 요청이 들어왔을 때 리소스 URI 마다 어떻게 처리할지 각각 정해두어야한다.

 

POST 메소드 사용 범위 정리

1. 새로운 리소스 생성(등록) 

- 서버가 식별하지 않은 새 리소스 생성

2. 요청 데이터 처리

- 단순 데이터 생성, 변경이 아닌 프로세스를 처리하는 경우 

 ex) 결제완료 -> 배달시작 -> 배달완료 처럼 프로세스의 상태가 변경되는 경우

 - 위와같이 서버에서 변화가 일어날 때 POST를 사용해야하는데, POST의 결과로 새로운 리소스가 생성되지 않을 수 있다. 이럴 때는 동사가 포함되는 URI인 컨트롤 URI로 설계한다.

 ex) POST /orders/{orderId}/start-delivey

3. 다른 메소드로 처리하기 애매한 경우

 - message body를 이용해 데이터를 조회할 때 GET 메소드를 사용하기 어려움
 - 서버에서 PATCH 메소드를 지원하지 않는 경우

 

 

2.1.3. PUT

리소스가 있으면 대체하지만 없을 경우 생성한다. 수정과 개념이 다르며 윈도우 파일의 덮어쓰기 원리와 유사하다. 클라이언트가 리소스의 전체경로를 알고 URI를 지정해 요청 메시지를 보낸다는 점에서 POST와 차이점을 가진다.

 

또한  리소스가 존재할 경우 완전대체하기 때문에 리소스 수정 시 주의해야한다.

ex) 리소스를 일부만 수정하려고 수정을 원하는 필드만 PUT으로 보낸경우 기존 리소스에 존재하던 필드는 모두 지워지고 새로 들어온 필드만을 가진 리소스가 생성된다.

 

2.1.4. PATCH

데이터를 수정(부분변경)하고 싶을 때는 PATCH를 이용한다. PUT과 달리 수정을 원하는 필드만 요청하더라도 다른 필드는 사라지지 않고 해당 필드만 수정된다. 

 

2.1.5. DELETE

리소스를 제거한다.

 

3. HTTP 메소드의 속성

3.1. 안전(safe)

호출해도 리소스를 변경하지 않는다면 안전하다. GET/HEAD는 조회만 하므로 리소스가 변경되지 않으므로 안전하지만 POST/DELETE/PUT/PATCH는 호출시 변경이 일어나므로 안전하지 않다.

안전의 기준은 호출하는 리소스만 고려하므로 호출로 인해 발생할 수 있는 장애는 고려하지 않는다.

 

3.2. 멱등(Idempotent)

똑같은 호출이 이루어지는 횟수에 상관없이 결과가 똑같다면 멱등 하다. 멱등은 내가 요청한 메세지가 TIMEOUT 등이 발생해 응답을 받지 못했을 때 클라이언트가 같은 요청을 다시해도 되는가의 판단 근거가 될 수 있다.

 

• GET : 조회가 여러번 이루어지더라도 똑같은 결과를 조회한다.
• PUT : 리소스가 여러번 대체되더라도 동일한 리소스로 대체되기 때문에 결과는 같다
• DELETE : 삭제를 여러번 호출하더라도 리소스는 삭제되어있다.
• POST : 멱등하지 않다. (주문하기/결제하기 등은 여러번 처리되면 안된다)

 

3.3. 캐시가능(Cacheable)

응답 결과(리소스)를 캐시해서 사용해도 되는가? 캐시한다는 것은 웹브라우저가 리소스를 저장해서 사용할 수 있는가를 기준으로 한다.

GET/HEAD/POST/PATCH가 캐시가능하지만, URL만 캐시키로 지정하면 되는 GET/HEAD와 다르게 본문 내용까지 캐시키로 지정해야하는 POST/PATCH는 구현에 어려움이 있다.

 

 

 

 

 

함께보면 좋은 글

RESTful API란? - 티스토리 블로그

HTTP 메소드 속성 요약표 - 위키피디아