HTTP는 응용 계층에서 정보를 주고 받는 데 사용되는 프로토콜입니다. '클라이언트 - 서버 구조 기반의 요청 - 응답 프로토콜'의 과정으로 정보를 주고 받습니다. 클라이언트가 HTTP 요청 메세지를 서버로 보내서 자원을 요청하면, 서버는 HTTP 응답 메세지로 요청받은 자원을 응답합니다.
HTTP는 주고받을 자원의 특성과 무관하게 자원을 주고받을 수단의 역할만을 수행합니다.
그래서 HTML, JPEG, PNG, JSON, XML 등 다양한 종류의 자원을 주고받을 수 있습니다.
HTML에서 메세지로 주고받는 자원의 종류를 미디어 타입이라 명칭. 혹은 MIME 타입이라고도 부릅니다. HTTP는 주고받을 미디어 타입에 특별히 제한을 두지 않고 독립적으로 동작이 가능한
미디어 독립적인 프로토콜입니다.
미디어 타입중 타입은 데이터의 유형을 나타내고 서브 타입은 주어진 타입에 대한 세부 유형을 나타냅니다. 타입을 표시하는 방식은 [타입/서브타입]입니다. 만약 'image/*'로 표시되어 있다면 image 타입의 모든 서브 타입을 나타낸다는 의미와 동일합니다.
HTTP는 상태를 유지하지 않는 Stateless 프로토콜입니다. 서버가 HTTP 요청을 보낸 클라이언트와 관련된 상태를 기억하지 않는다는 의미입니다. 그래서 기본적으로 클라이언트의 모든 HTTP 요청은 기본적으로 독립적인 요청으로 간주합니다.
상태를 유지하지 않게 되면 장점이 많습니다. HTTP 서버는 일반적으로 많은 클라이언트와 동시에 상호 작용하기 때문에 동시에 처리해야 할 요청 메세지의 수가 많을 수 있지만 클라이언트의 상태를 유지하지 않기 때문에 서버에 부담이 없습니다. 그리고 서버가 여러 대로 구성되어 보통 유지되며 대부분의 상용 서비스는 서버를 여러 대로 운영합니다. 이 경우에도 서버가 상태를 유지하지 않기 때문에 분산해 둔 서버 간에 정보를 공유하는 작업에 부담이 없습니다.
HTTP가 상태를 유지하는 프로토콜이었다면, 클라이언트는 특정 서버에 종속될 수 있습니다. 자신의 상태를 기억하는 특정 서버만 상호작용 할 수 있기 때문입니다. 그럼 한 서버에서 문제가 생기면 그 서버에 종속된 클라이언트의 문제가 생기기 직전까지의 HTTP 통신 내역을 모두 분실하는 상황이 발생할 가능성이 있습니다.
Stateless라서 HTTP는 확장성과 견고성이라는 목표를 달성할 수 있습니다. 상태를 유지하지 않는 특성으로 인해 언제든 쉽게 서버를 추가할 수 있어서 확장성을 확보했고, 서버 중 하나에 문제가 생기더라도 다른 서버로 대체가 가능해서 운영의 견고성을 확보했습니다.
HTTP 1.1 이상 버전부터 지속 연결이라는 기술을 제공합니다. 혹은 Keep-alive라고 부릅니다. 하나의 TCP 연결상에서 여러 개의 요청-응답을 주고받을 수 있는 기술입니다. 비지속 연결은 매번 새롭게 연결을 수립하고 종료해야 하지만, 지속 연결 HTTP는 그렇지 않기 때문에 요청과 응답을 더 신속하게 처리할 수 있습니다.
HTTP 메세지는 요청 혹은 응답 메세지입니다.
요청 메세지라면 시작 라인은 요청 라인이 되고, 응답 메세지라면 '상태 라인'입니다.
요청 메세지
요청 라인
메서드, 요청 대상, HTTP 버전으로 구성되어 있습니다.
메서드
클라이언트가 서버의 자원에 대해 수행할 작업을 인지할 수 있습니다.
개발을 하면서 API를 요청할 때 엄청나게 자주 봤을 GET, POST, PUT, DELETE를 의미합니다.
만약 요청 대상(URI 경로)가 같더라도 메서드가 다르면 서로 다른 요청으로 간주합니다.
요청 대상
HTTP 요청을 보낼 서버의 자원을 의미. URI 경로가 요청 대상입니다.
HTTP 버전
사용된 HTTP 버전을 의미합니다.
응답 메세지
상태 라인
HTTP 버전, 상태 코드, 이유 구문으로 구성됩니다.
HTTP 버전
요청 메세지와 동일합니다.
상태 코드
요청에 대한 결과를 나타내는 세 자리의 정수입니다.
404, 400, 500, 200, 401 등등 개발을 하면서 요청을 보내고 응답을 받을 때 개발자 도구의 '네트워크' 탭에서 확인할 수 있는 status code입니다.
이유 구문
상태 코드에 대한 문자열 설명입니다.
예를 들어 '200'은 요청이 성공적으로 받아들여져 수행되었음을 의미합니다.
이걸 이유 구문까지 같이 표기하면 '200 OK'입니다.
필드 라인에는 0개 이상의 HTTP 헤더가 명시합니다. 그래서 헤더 라인이라고 부르기도 합니다.
HTTP 헤더
HTTP 통신에 필요한 부가 정보를 담는 곳입니다. 개발을 하면 HTTP 메세지에 다양한 헤더를 사용합니다. 필드라인에 명시되는 각 HTTP 헤더는 콜론(:)을 기준으로 헤더 이름과 하나 이상의 헤더 값으로 구성됩니다.
HTTP 본문
HTTP 요청 혹은 응답 메세지에서 본문(body)이 필요한 경우에는 메세지 본문에 명시합니다.
본문은 요청에서 존재하지 않을 수도 있고 다양한 콘텐츠 타입이 사용될 수 있습니다.
자원을 조회할 때 사용하는 메서드입니다.
GET은 개발할 때 가장 흔하게 사용하며 웹 브라우저에서도 흔히 사용합니다.
GET 메서드를 사용할 때는 요청 메세지 본문을 포함시키지 않는 것이 바람직합니다.
그래서 보통 메세지 본문보다는 쿼리 스트링(쿼리 파라미터)을 사용하는 경우가 일반적입니다.
GET과 동일한 역할을 하지만 응답 메세지에 본문이 포함되지 않는 메서드입니다.
응답의 헤더만을 조회할 수 있는 요청 메서드입니다.
서버로 특정 작업을 처리하도록 요청하는 메서드입니다. 범용성이 매우 넓습니다.
개발을 하면서 GET 다음으로 가장 많이 사용하는 것이 POST입니다.
클라이언트가 서버로 하여금 새로운 자원을 생성하게 만들도록 사용하는 메서드입니다. POST 요청이 성공해서 새로운 자원이 서버에 생성되면 서버는 응답 메세지의 Location 헤더를 통해 생성된 자원의 위치를 클라이언트에게 공지합니다.
서버에 덮어쓰기를 요청하는 메서드입니다. 요청 자원이 존재하지 않는다면 메세지 본문으로 초기 자원을 새로 생성하거나 이미 자원이 존재한다면 메세지 본문으로 자원을 완전히 대체하는 메서드입니다.
자원의 일부 수정을 요청하는 메서드입니다.
PUT과는 다르게 부분적으로 수정하는 것과 동일합니다.
특정 자원을 삭제하고 싶을 때 사용하는 메서드입니다.
| 상태 코드 | 설명 |
|---|---|
| 100번대 | 정보성 상태 코드 |
| 200번대 | 성공 상태 코드 |
| 300번대 | 리다이렉션 상태 코드 |
| 400번대 | 클라이언트 에러 상태 코드 |
| 500번대 | 서버 에러 상태 코드 |
| 상태 코드 | 이유 구문 | 의미 |
|---|---|---|
| 200 | OK | 요청 성공 |
| 201 | Created | 요청 성공, 새로운 자원 생성 |
| 202 | Accepted | 요청을 받았으나, 요청한 작업을 끝내지 않았음 |
| 204 | No Content | 요청 성공, 메세지 본문으로 표시할 데이터가 없음 |
| 상태 코드 | 이유 구문 | 의미 |
|---|---|---|
| 301 | Moved Permanently | 영구적 리다이렉션, 재요청 메서드 변경될 수 있음 |
| 308 | Permanent Redirect | 영구적 리다이렉션, 재요청 메서드 변경되지 않음 |
300번대 코드는 클라이언트가 요청한 자원이 다른 URL에 있을 때, 클라이언트의 요청을 해당 URL로 이동시키는 상태 코드를 포함합니다. 만약 어떤 URL에 요청을 보낸 결과로 영구적인 리다이렉션 관련 상태 코드를 응답받았다면, 요청을 보낸 URL은 기억할 필요가 없다고 봐도 무방합니다.
반면 일시적인 리다이렉션은 자원의 위치가 임시로 변경되었거나 임시로 사용할 URL이 필요한 경우 주로 사용합니다. 그래서 어떤 URL에 대해 일시적인 리다이렉션 관련 상태 코드를 응답받았다면 요청을 보낸 URL은 기억이 필요합니다.
| 상태 코드 | 이유 구문 | 의미 |
|---|---|---|
| 302 | Found | 일시적 리다이렉션, 재요청 메서드 변경될 수 있음 |
| 303 | See Other | 일시적 리다이렉션, 재요청 메서드 GET으로 변경 |
| 307 | Temporary Redirect | 일시적 리다이렉션, 재요청 메서드 변경되지 않음 |
| 상태 코드 | 이유 구문 | 의미 |
|---|---|---|
| 400 | Bad Request | 클라이언트의 요청이 잘못되었음 |
| 401 | Unauthorized | 요청한 자원에 대한 유효한 인증이 없음 |
| 403 | Forbidden | 요청이 서버에 의해 거부됨 |
| 404 | Not Found | 요청받은 자원을 찾을 수 없음 |
| 405 | Method Not Allowed | 요청한 메서드를 지원하지 않음 |
웹상에서 정보를 검색할 때 모든 자원에 접근이 가능한 것은 아닙니다. 특정 자원에 접근하기 위해서는 인증이 필요할 때가 있습니다. 요청에 대한 인증이 필요한데 인증을 위한 정보를 헤더나 본문에 담아서 보내지 않았을 경우 서버는 401 상태 코드를 반환합니다. 서버에서는 상태 코드가 401이라면 클라이언트에게 WWW-Authenticate라는 헤더를 통해서 인증 방법을 알려주야 합니다.
클라이언트가 정보를 담아서 보내더라도 권한이 충분하지 않다면 403 상태 코드로 응답합니다. 403은 위에서 볼 수 있듯이 요청이 거부된 것으로 자원에 접근할 권한이 없음을 의미합니다.
중요한 포인트는 401과 403은 아예 다른 개념입니다. 401은 인증, 자신이 누구인지 증명하는 것을 의미하고 403은 권한 여부, 인증되어있는가를 의미 = 인가 여부를 확인하는 것을 의미합니다.
404는 아예 자원이 존재하지 않음을 알리는 상태 코드입니다. 하지만 존재하는데 공개하지 않기 위해서 404를 응답으로 보내는 경우도 존재합니다.
| 상태 코드 | 이유 구문 | 의미 |
|---|---|---|
| 500 | Internal Server Error | 요청을 처리할 수 없음 |
| 502 | Bad Gateway | 중간 서버의 통신 오류 |
| 503 | Service Unavailable | 현재는 요청을 처리할 수 없으나 추후 가능할 수도 있음 |
500번대 상태 코드도 개발 중에 마주칠 수 있습니다. 서버에서 아직 만들어두지 않은 작업에 대해 요청을 하면 응답으로 500이나 503을 보내는 경우도 존재합니다.
이 경우에는 본인이 프론트엔드 개발자라면 서버 개발자에게 해당 API가 요구하는 서버의 작업을 개발했는지 혹은 오류가 있는지 확인하는 과정이 필요합니다.