HTTP 프로토콜
웹 서버와 웹 클라이언트 사이에서 데이터를 주고받기 위해 사용하는 통신방식으로, TCP/IP 프로토콜 위에서 동작한다.
HTTP 메시지의 구조
HTTP 메시지는 클라이언트에서 서버로 보내는 요청 메시지와 서버에서 클라이언트로보내는 응답 메시지 2가지가 있다. 그 구조는 아래와 같다.
- 스타트라인: 요청라인 또는 상태라인
- 헤더: 헤더는 생략 가능
- 빈 줄: 헤더의 끝을 빈 줄로 식별
- 바디: 바디는 생략 가능
스타트라인은 요청 메시지일 때 요청라인이라 하고, 응답 메시지일 때 상태라인이라고 한다.
헤더는 각 행의 끝에 줄 바꿈 문자인 CRLF가 있으며, 헤더와 바디는 빈 줄로 구분한다.
바디에는 텍스트뿐만 아니라 바이너리 데이터도 들어갈 수 있다.
- 바디가 없는 요청 메시지
GET /book/shakespeare HTTP/1.1
HOST: www.example.com:8080
첫 번째 줄: 요청라인
으로, 요청 방식(method)
, 요청 URL
, 프로토콜 버전
으로 구성된다.
두 번째 줄: 헤더
로, 이름: 값
형식으로 표현하며, 여러 줄도 가능하다. 또한, HOST
항목은 필수로 표시해줘야 한다. 요청라인의 URL에 HOST를 표시하면 HOST 헤더는 생략할 수 있다. PORT 번호 또한 같이 표시.
GET http://www.example.com:8080/book/shakespeare HTTP/1.1
- 응답 메시지
HTTP/1.1 200 OK
Content-Type: application/xhtml+xml; charset=utf-8
<html>
...
</html>
첫 번째 줄: 상태라인
은 프로토콜 버전
, 상태 코드
, 상태 텍스트
로 구성된다. 서버에서 처리 결과를 상태라인에 표시한다.
두 번째 줄: 헤더
로 예시에서는 헤더가 하나뿐인 응답 메시지로, 바디가 있어 빈 줄로 구분한다.
URI vs URL
URI는 Uniform Resource Indentifier 의 약자로 URL(Uniform Resource Locator)와 URN(Uniform Resource Name)을 포함하는 더 넓은 의미의 표현
HTTP 처리 방식
HTTP 메소드를 통해서 클라이언트가 원하는 처리 방식을 서버에 알려준다.
- GET: 리소스 취득
- POST: 리소스 생성, 리소스 데이터 추가
- PUT: 리소스 변경
- DELETE: 리소스 삭제
- HEAD: 리소스의 헤더(메타데이터) 취득
- OPTIONS: 리소스가 서포트하는 메소드 취득
- TRACE: 루프백 시험에 사용
- CONNECT: 프록시 동작의 터널 접속으로 변경
html 폼에서 사용자가 입력한 데이터를 서버로 보낼 때, GET또는 POST 메소드를 사용한다. Django의 경우 폼의 데이터는 POST 방식만을 사용한다.
상태 코드
서버에서의 처리 결과는 응답 메시지의 상태라인에 있는 상태 코드를 보고 파악할 수 있다.
상태 코드는 세 자리 숫자로, 첫 번째 숫자는 HTPP 응답의 종류를 구분, 나머지 두 개의 숫자는 세부 응답 내용을 구분한다.
- 1xx Informational 임시적인 응답으로, 현재 클라이언트의 요청까지 처리되었으니 계속 진행바람
- 2xx Success 클라이언트의 요청이 서버에서 성공적으로 처리되었음
- 3xx Redirection 완전한 처리를 위해서 추가적인 동작을 필요로 함. 주로 서버의 주소 또는 요청한 URI의 웹 문서가 이동되었으니, 그 주소로 다시 시도해보라는 의미
- 4xx Client Error 없는 페이지를 요청하는 것처럼 클라이언트의 요청 메시지 내용이 잘못된 경우
- 5xx Server Error 서버 측 사정에 의해 메시지 처리에 문제가 발생한 경우. 서버의 부하, DB 처리 오류, 서버 익셉션 발생 등
URL 설계
- URL 스킴: URL에 사용된 프로토콜
- 호스트명: 웹 서버의 호스트명으로, 도메인명 또는 IP 주소로 표현
- 포트번호: 웹 서버 내의 서비스 포트번호. 생략 시 디폴트 포트번호로, http는 80, https는 443
- 경로: 파일이나 애플리케이션 경로를 의미
- 쿼리스트링: 질의 문자열로,
&
로 구분된이름=값
쌍 형식으로 표현 - 프래그먼트: 문서 내의 앵커 등 조각을 지정
RPC와 REST
URL은 웹 클라이언트에서 호출한다는 시점에서 웹 서버에 존재하는 애플리케이션에 대한 API
API의 명명 규칙을 정하는 방법으로 URL을 RPC로 보는 방식과 REST로 바라보는 방식이다
RPC(Remote Procedure Call)
클라이언트가 네트워크상에서 원격에 있는 서버가 제공하는 API 함수를 호출하는 방식
URL 설계와 API 설계를 동일하게 고려하여 URL의 경로를 API 함수명으로, 쿼리 파라미터를 함수의 인자로 간주한다. 때문에, 웹 클라이언트에서 URL을 전송하는 것이 웹 서버의 API 함수를 호출한다고 인식한다. URL 경로가 동사(함수) 의 형태를 띔
http://blog.example.com/search?q=test&debug=true
REST(Representational State Transfer)
웹 서버에 존재하는 요소들을 모두 리소스로 정의. URL을 통해 웹 서버의 특정 리소스를 표현하는 개념으로 클라이언트와 서버 간에 데이터의 교환을 리소스 상태의 교환으로 간주. 리소스의 조작을 HTTP 메소드로 구분한다.
http://blog.example.com/search/test # GET 메소드의 사용으로 REST가 인식