주제
Q 1 : HTTP 메시지 구조는?
Q 2 : HTTP API를 어떤 방식으로 만들면 좋을까?
Q 3 : HTTP 메서드는(GET)?
Q 4 : HTTP 메서드는(POST)?
Q 1 : HTTP 메시지 구조는?
HTTP 메시지는 ‘시작라인(Strat-Line)’, ‘헤더(Header)’, ‘공백라인(Empty-Line == CRLF)’, ‘메시지 바디(Message Body)’로 구성된다. HTTP 요청 메시지의 시작라인(Start-Line)은 Request-Line으로 부를 수 있다. Request-Line은 'Method, Request-Target, HTTP-Version의 구조를 갖는다. GET(Method : 서버가 수행해야할 동작을 지정)에 해당하고 /search?q=hello&hl=ko(Request-Target)가 된다. HTTP/1.1(HTTP-Version)이다. 그 다음 Header에 Header-Filed는 filed-name”:” 띄워쓰기허용(OWS) filed-value OWS 이렇게 구성된다. Host: www.google.com(도메인)을 갖는다. CRLF(공백 라인).
응답 메시지의 경우 시작라인(Start-Line)은 ‘Status-Line’으로 불린다. 응답 메시지의 Status-Line은 HTTP-Version, Status-Code, Reason-Phrase CRLF의 구조다. HTTP/1.1(HTTP-Version SP), 200(Status-Code), OK(Reson-Phrase : 사람이 이해할 수 있는 짧은 상태 코드), CRLF(공백라인), Message Body.
응답 메시지의경우 HTTP 헤더 용도는 HTTP 전송에 필요한 모든 부가 정보가 있다. 예를 들면 메시지 바디 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트 정보, 서버 애플리케이션 정보, 캐시 관리 등이 있다.
HTTP Body는 실제 전송할 데이터. HTML 문서, 이미지, 영상, JSON, 등 Byte로 표현할 수 있는 모든 데이터 전송이 가능하다.
Q 2 : HTTP API를 어떤 방식으로 만들면 좋을까?
HTTP API를 설계할 때 가장 중요한 건 리소스(Resource)다. 예를 들면 회원을 등록하고 수정하고 조회하는 게 리소스가 아니다. 미네랄을 캐라라고 하면 ‘미네랄’이 리소스다. ‘회원’이라는 개념 자체가 바로 리소스다. 어떻게 리소스를 식별하는 게 좋을까? 회원을 등록하고 수정하고 조회하는 것을 모두 배제 먼저 하자. 회원이라는 리소스만 식별 하돼 회원 리소스를 URI에 매핑하자. URI는 계층구조를 갖는다.
리소스 URI Question 회원 목록조회 /members 회원 조회 /members/{id} 어떻게 구분할까? 회원 등록 /members/{id} 어떻게 구분할까? 회원 수정 /members/{id} 어떻게 구분할까? 회원 삭제 /members/{id} 어떻게 구분할까?
여기서 핵심은 리소스와 행위(메서드)를 분리해보자. 리소스는 ‘회원’이지만 행위는 ‘조회, ‘등록’, 수정’, ‘삭제’.
자, 그렇다면 행위(메서드)를 어떻게 구분하면 좋을까?
Q 3 : HTTP 메서드는(GET)?
GET의 역할은 리소스를 조회하는데 있다. <그림1>처럼 클라이언트가 서버에 전달하고 싶은 데이터는 Query(쿼리 파라미터 or 쿼리 스트링)을 통해 전달한다. 메시지 바디를 사용해 데이터를 전달 할 수 있지만 지원하지 않는 곳이 많아서 관장하지 않는다.
<그림2>처럼 서버의 응답 메시지를 받은 클라이언트는 100번째 회원을 정보를 받았다. HTTP Header의 정보는 HTTP-Version(HTTP/1.1)에 Status-Code(200) OK를 받았다. Type은 애플리케이션/JSON이다. 문자 길이는 34다. HTTP Body의 정보는 이름은 young이고 나이는 20살.
Q 4 : HTTP 메서드는(POST)?
HTTP 메서드의 POST는 요청 데이터를 처리한다. 메시지 바디를 통해 서버로 요청 데이터를 전달한다. 서버는 요청 데이터를 처리한다. HTTP 메서드의 POST가 메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행한다. 주로 전달된 데이터로 신규 리소스 등록, 프로세스 처리에 사용된다.
<그림5>를 신규 리소스 생성이라고 가정하면 <그림6>은 신규 리소스 식별자를 생성하는 과정을 보여준다. 클라이언트의 POST 요청을 메시지를 받은 서버는 HTTP Body에 있는 데이터를 확인 후 데이터베이스에 등록을 하고 신규 아이디를 생성한다. 신규 리소스 식별자를 생성한다.
서버가 보낸 POST 응답 메시지를 받은 클라이언트는 신규 리소스가 생성 됐기에 보통 201 Created 상태 코드를 보낸다. 201로 보낼 때 자원이 생성된 경로인 Location을 함께 보낸다. HTTP Body에는 등록된 정보를 다시 함께 보내준다.
Q : 그렇다면 POST는 요청 데이터를 어떻게 처리한다는 뜻일까?
A :POST는 의미가 많다. 보통 “데이터가 등록된다.”라는 의미로만 공부할 때가 많은데 사실 그것만 있는 게 아니다.
1) ‘HTML Form’에 입력한 정보로 회원가입과 주문 등에서 사용되는 경우
2) 게시판, 뉴스 그룹, 메일링 리스트, 블로그 등 메시지를 쓸 때
3) 서버가 아직 식별하지 않은 새 리소스 생성할 때(신규 주문 생성)
4) 기존 자원에 데이터 추가하기(한 문서 끝에 내용 추가하기)
*리소스 URI에 POST 요청이 되면 요청 데이터를 어떻게 처리할지 리소스마다 따로 정해야 한다.
Post 정리
- 1) 새 리소스 생성(등록)
서버가 아직 식별하지 않은 새 리소스 생성- 2) 요청 데이터 처리
단순히 데이터를 생성하거나 변경하는 것을 넘어서 프로세스를 처리해야하는 경우
예) 주문에서 결제완료 → 배달 시작 → 배달완료처럼 단순히 값 변경을 넘어 프로세스의 상태가 변경되는 경우
POST의 결과로 새로운 리소스가 생성되지 않을 수도 있음.
예) POST /orders/{orderId}/start-delivery(컨트롤 URI)
리소스만 안될 때가 있는데 위의 경우처럼 처리할 수도 있음.- 3) 다른 메서드로 처리하기 애매한 경우
예) JSON으로 조회 데이터를 넘겨야 하는데, GET 메서드를 사용하기 어려운 경우
애매하면 POST
참고자료
김영한 인프런 강의 : 모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의
