HTTP 메세지 구조
•
시작라인
◦
HTTP 요청 메세지
▪
메서드의 종류(GET/POST/PUT/DELETE 등) 표시
▪
요청 대상 경로(URL) 표시
▪
사용된 HTTP version 표시
◦
HTTP 응답 메세지
▪
클라이언트가 보낸 요청에 대한 성공 실패 여부에 대한 상태 코드(status code) 표시(ex : 404)
▪
상태 코드에 대한 결과를 사람이 이해할 수 있는 표현으로 표시(ex : Not Found)
▪
사용된 HTTP version 표시
•
헤더
◦
HTTP 전송에 필요한 모든 부가 정보들을 담고 있다.(메세지 길이, 인코딩 종류, 압축여부, 브라우저 정보 등)
•
공백 라인
◦
헤더와 바디를 구분하기 위한 라인
•
메세지 바디
◦
실제 전송할 데이터를 담고 있다.(HTML 문서, 이미지, 영상, JSON 등)
HTTP 메서드 종류
•
GET
◦
리소스 조회 메서드(Read)
◦
리소스를 조회할 때 주로 사용되는 메서드로, 서버에 전달하고 싶은 데이터가 있다면 query(쿼리 파라미터, 쿼리 스트링)을 통해서 전달한다.
◦
조회할 때 POST를 사용할 수도 있지만 GET 메서드는 캐싱이 가능하기 때문에 GET을 사용하는게 유리하다.
•
POST
◦
전달한 데이터 처리/생성 요청 메서드(Create)
◦
주로 신규 리소스를 등록하거나 프로세스를 처리하는데 사용되며, 요청 데이터를 처리하거나 메세지 body를 통해 서버로 데이터를 전달한다.
◦
서버는 메세지 body를 통해 들어온 데이터를 처리하는 모든 기능을 수행한다. 다른 메서드로 처리하기 애매할 때도 사용된다.
•
PUT
◦
리소스를 대체(수정)하는 메서드(Update)
◦
리소스가 없다면 새로 생성하고, 리소스가 있다면 해당 리소스를 대체한다.
◦
위의 메세지에서 username 없이 보내게 되면 age만 수정하는 것이 아닌 username 필드가 삭제된다. 이처럼 PUT은 아예 리소스를 덮어버리기 때문에 사용에 주의해야한다.
•
PATCH
◦
리소스의 일부분을 변경하는 메서드(Update)
◦
PATCH를 지원하지 않는 서버에서는 POST를 사용할 수 있다.
•
DELETE
◦
리소스를 제거하는 메서드(Delete)
◦
상태코드는 대부분 200을 사용하며, 상황에 따라 204를 사용한다.
HTTP 메서드 속성
•
안전
◦
해당 메서드를 호출하더라도 리소스가 변경되지 않는 성질
◦
GET과 같이 데이터를 단순 조회만 하는 경우에 리소스를 변경 및 수정하지 않기 때문에 안전한 메서드이다.
•
멱등
◦
같은 메서드를 여러 번 호출하더라도 결과가 달라지지 않는 성질
◦
외부 요인으로 중간에 리소스가 변경되는 것까지는 고려하지 않는다.
◦
메서드가 멱등하다면 서버가 Timeout 등으로 정상 응답을 주지 못했을 때, 클라이언트가 같은 요청을 다시 보내도 되는 근거가 된다. → 자동 복구 메커니즘
•
캐시 가능
◦
메서드의 응답 결과를 캐싱해서 효율적으로 사용할 수 있는가에 대한 성질
◦
실무에서는 거의 GET과 HEAD 정도만 캐시로 사용된다.
클라이언트에서 서버로 데이터 전송하기
•
이미지나 텍스트 문서와 같이 정적 데이터 조회 → GET 메서드
•
정렬 필터나 검색과 같은 동적 데이터를 전송하기(query parameter를 통해 전송) → GET 메서드
•
회원 가입, 상품 주문, 회원 정보 수정 등(message body를 통해 전송) → POST 메서드
URL 설계 개념
•
문서
◦
파일 한개, 객체 인스턴스, 데이터베이스 row처럼 단일 개념을 말한다.
◦
예시 : /members/100, /files/star.jpg
•
컬렉션
◦
서버가 관리하는 리소스 디렉터리로, 서버가 리소스의 URI를 생성하고 관리한다.
◦
예시 : /members
•
스토어
◦
클라이언트가 관리하는 자원 저장소로, 클라이언트가 리소스의 URI를 관리한다.
◦
예시 : /files/star.jpg
•
컨트롤 URI
◦
문서, 컬렉션, 스토어로 해결하기 어려운 경우 사용되며, URI에 동사를 직접 사용하여 리소스를 식별한다.
◦
예시 : /members/{id}/delete
URL 설계
•
URL 설계는 리소스를 식별할 수 있도록 해야하고, 리소스와 행위를 분리하는 것이 권장된다.
•
회원을 등록하고 조회하고 수정하는 로직이 있다면, 회원 자체가 리소스인 것이다.
•
회원이라는 리소스에 조회, 등록, 삭제, 변경이라는 행위는 메서드를 통해 구분하는 것이 바람직하다.
•
예시
◦
회원 등록 → /members + POST 메서드
◦
회원 조회 → /memebers + GET 메서드
◦
회원 탈퇴 → /members + DELETE 메서드
◦
회원 정보 변경 → /members + PATCH 메서드
웹 브라우저 요청 흐름
1.
DNS 서버 조회
•
DNS를 입력하여 접근 요청 시 DNS 서버에 접속하여 해당 도메인 이름에 맞는 IP 주소를 찾아 받아온다.
2.
클라이언트에서 HTTP 요청 메세지 생성
•
주소와 요청 형태, 요청 데이터에 맞춰 HTTP 요청 메세지를 생성한다.
3.
클라이언트에서 서버로 HTTP 메세지 전송
•
프로토콜에 맞춰 패킷을 생성하고 네트워크를 통해 데이터를 서버에 전송한다.
4.
서버에서 HTTP 응답 메세지 생성 및 클라이언트로 전송
•
HTTP 요청의 응답에 맞춰 HTTP 응답 메세지를 생성한다.
5.
웹 브라우저 HTML 렌더링
•
응답 메세지를 통해 받은 데이터로 클라이언트에서 HTML 렌더링한다.