[강의] 모든 개발자를 위한 HTTP 웹 기본 지식 03-05 HTTP 기본, HTTP 메서드, HTTP 메서드 활용
모든 개발자를 위한 HTTP 웹 기본 지식 강의
김영한님의 인프런 강의(모든 개발자를 위한 HTTP 웹 기본 지식) 을 수강하면서 강의 내용을 일부 발췌해 요약한 글.
섹션 3 HTTP 기본
HTTP(HyperText Transfer Protocol)
하이퍼텍스트를 전송하는 프로토콜으로 HTML, TEXT뿐만 아니라 이미지, 음성, 영상, 파일, JSON, XML 등 거의 모든 형태의 데이터가 전송 가능하며 서버 간 데이터를 주고 받을 때도 대부분 HTTP를 사용한다. HTTP/1.1, HTTP/2는 TCP 기반, HTTP/3은 UDP 기반이며 현재는 HTTP/1.1을 주로 사용한다.
HTTP는 클라이언트 서버 구조로, 클라이언트는 서버에 요청 후 응답을 받고 동작한다. 항상 같은 서버가 유지되어야 하는 Stateful(상태 유지)과 달리 Stateless(무상태)는 응답 서버를 쉽게 바꿀 수 있어 서버 장애 시 빠른 대응과 무한한 서버 증식(스케일 아웃)이 가능하다. 그러나, 모든 것을 무상태로 설계할 수 있지는 않다. 무상태의 경우 전송되는 데이터량이 비교적 많고, 로그인과 같은 경우는 상태 유지가 필요하다. 이러한 경우 브라우저 쿠키나 서버 세션을 사용해 상태를 유지하는데, 결론적으로 웹 애플리케이션 설계 시에는 최소한의 상태 유지를 사용하는 것이 좋다. HTTP는 기본적으로 연결을 유지하지 않는 모델으로, 클라이언트의 요청에 응답 후 연결을 끊어 서버 자원을 효율적으로 사용한다. 즉. 클라이언트와 서버가 요청과 응답을 주고받으면 연결이 끊어지고, 클라이언트가 다시 요청하면 서버는 이전 요청을 기억하지 못한다. 그러나 이러한 방식은 TCP/IP 연결을 매번 새로 맺어야 하므로 비교적 시간이 소요되며, 웹 브라우저로 사이트 요청 시에는 매번 수많은 자원들이 다운로드되는 한계가 있어 지속 연결(Persistent Connections) 을 사용한다.
HTTP 메시지 구조를 정리하면 다음과 같이 단순하며 확장 가능하다.
섹션 4 HTTP 메서드
API URI 설계
가장 중요한 것은 리소스 식별 이다. 회원 관리 예제에서 리소스는 회원 등록, 수정, 조회가 아닌 회원 그 자체이다. 회원이라는 리소스를 URI에 매핑하고 URI의 계층 구조를 활용한다. 리소스와 리소스를 대상으로 하는 행위를 분리하는 것이 바람직하다.
HTTP 메서드
주요 메서드로는 GET, POST, PUT, PATCH, DELETE가 있으며, 기타 메서드로는 HEAD, OPTIONS, CONNECT, TRACE가 있다.
GET
리소스를 조회하는 메서드로, 서버에 전달하고자 하는 데이터는 쿼리를 통해 전달한다. 메시지 바디를 통해 데이터를 전달할 수 있지만 권장하지는 않는다.
POST
요청 데이터를 처리하는 메서드로, 주로 등록에 사용한다. 메시지 바디를 통해 서버로 요청 데이터를 전달하면 서버는 요청 데이터를 처리한다. 등록 외에도 HTML 양식에 입력된 필드와 같은 데이터 블록을 데이터 처리 프로세스에 제공하거나 게시판 등에 메시지를 개시하거나 기존 자원에 데이터를 추가하는 것 등 요청 데이터를 처리하는 데도 사옹된다.
PUT
리소스가 있으면 대체하고 해당 리소스가 없으면 생성하는 메소드로, 클라이언트가 리소스를 식별(리소스의 위치를 알고 URI를 직접 지정)한다는 점에서 POST와 차이가 있다. 리소스를 수정하는 게 아니라 완전히 대체한다는 점을 주의하자.
PATCH
리소스를 부분 변경하는 메서드이다. PATCH가 지원되지 않는 서버는 POST를 사용하면 된다.
DELETE
리소스 삭제하는 메서드이다.
HTTP 속성
- 안전(Safe): 호출해도 리소스를 변경하지 않는다.
- 멱등(Idempotent): 몇번 호출하든 결과가 같다. 서버에서 응답이 없을 때 재시도가 가능한가?에 대한 판단 근거가 된다.(자동 복구 매커니즘)
- 캐시가능(Cacheable): 응답 결과 리소스를 캐시해서 사용해도 되는가? GET, HEAD, POST, PATCH가 가능하나 실제로는 GET, HEAD 정도만 캐시로 사용한다.
https://en.wikipedia.org/wiki/HTTP
섹션 5 HTTP 메서드 활용
데이터 전송 (클라이언트 -> 서버)
클라이언트에서 서버로 데이터를 전송하는 방법은 크게 두 가지가 있다.
- 쿼리 파라미터를 통한 데이터 전송: GET, 주로 정렬 필터(검색어)에 사용한다.
- 메시지 바디를 통한 데이터 전송: POST, PUT, PATCH, 회원 가입, 상품 주문, 리소스 변경 등에 주로 사용한다.
데이터 전송을 크게 4가지 상황으로 정리해보면 다음과 같다.
정적 데이터 조회 이미지나 정적 텍스트 문서같은 경우 GET을 사용하고 쿼리 파라미터 없이 경로로 단순하게 조회가 가능하다.
동적 데이터 조회 검색, 필터, 정렬 조건에 주로 사용되며 GET을 사용, 쿼리 파라미터를 사용해 데이터를 전달한다.
HTML Form 데이터 전송 회원 가입, 상품 주문 등의 경우에 POST 전송. GET 전송도 가능하긴 하다. Content-Type은 application/x-www-form=urlencoded를 사용하며 form의 내용을 메시지 바디를 통해 key=value 쿼리 파라미터 형식으로 전송되고, 전송 데이터는 url encoding 처리 된다. Content-Type: multipart/form-data의 경우는 여러 데이터 타입의 전송이 가능하며, 주로 파일 업로드와 같은 바이너리 데이터를 전송할 때 사용한다.
HTTP API 데이터 전송
서버-서버 백엔드 시스템 통신이나 앱 클라이언트, 웹 클라이언트에서 사용한다. POST, PUT, PATCH의 경우 메시지 바디를 통해 데이터를 전송하고, GET의 경우 쿼리 파라미터로 데이터를 전달한다. Content-Type: application/json을 주로 사용한다.
HTTP API 설계 예시
HTTP API
- POST 기반: 회원 등록을 /members 에서 POST 하는 경우 클라이언트는 등록될 리소스의 URI를 모른다. 이처럼 서버가 리소스의 URI를 생성하고 관리하는 리소스 디렉토리를 컬렉션(Collection) 이라고 한다.
- PUT 기반: 파일을 조회/등록/삭제하는 경우는 클라이언트가 리소스 URI를 알고 있어야 한다. 이처럼 클라이언트가 직접 리소스의 URI를 지정하는 경우 클라이언트가 관리하는 리소스 저장소를 스토어(Store) 라고 한다.
신규 자원을 등록할 때, 대부분 POST 기반이다.
HTML FORM
순수 HTMl, HTML FORM에서는 GET, POST만 지원한다고 생각하면 된다. GET, POST 만으로는 제약이 있어 이를 해결하기 위해 동사로 된 리소스 경로를 사용한다. 컨트롤 URI 예를 들어 POST의 /new, /edit, /delete 는 모두 컨트롤 URI이다. 최대한 리소스로 URI를 설계하고 해결이 어려운 경우에만 컨트롤 URI를 사용하는 방식이 바람직하다.
참고하면 좋은 URI 설계 개념
https://restfulapi.net/resource-naming/에 자세히 설명되어 있다.