HTTP 특성

1. 비연결성 (Connectionless)
클라이언트와 서버가 한 번 연결을 맺은 후, 클라이언트 요청에 대해 서버가 응답을 마치면 맺었떤 연결을 끊어버리는 성질

장점
연결을 유지하기 위해 리소스를 줄이면 더 많은 연결을 할 수 있으므로
(HTTP는 인터넷 상에서 불특정 다수의 통신 환경을 기반으로 설계돼있음 계속 유지하려면 많은 리소스 발생)

단점
서버는 클라이언트를 기억하고 있지 않으므로 동일한 클라이언트의 모든 요청에 대해 매번 새로운 연결을 시도/해제 과정을 거침
이에 대한 오버헤드가 발생

KeepAlive
오버헤드 발생에 대한 해결책으로 사용할 수 있는 KeepAlive 속성
지정된 시간동안 서버와 클라이언트 사이에서 패킷 교환이 없을 경우, 상대방의 안부를 묻기 위해 패킷을 주기적으로 보내는 것. 이때 패킷에 반응이 없으면 접속을 끊게 됨
KeepAlive 속성이 On 상태라해도 서버가 바쁜 환경에서는 프로세스 수가 기하급수적으로 늘어나기 때문에 KeepAlive로 상태를 유지하기 위한 메모리를 많이 사용하게 되므로 주의해야 함.


2. 무상태
Connetionless로 인해 서버는 클라이언트를 식별할 수 없는데 이것을 Stateless라고 함 (무한 로그인(인증) 해야 하는 번거로움 발생)

상태를 기억하는 법
쿠키/세션, OAuth, JWT(토크 기반 인증)


3. 응답 상태코드
클라이언트가 서버에 요청을 하면 서버는 요청에 대한 처리 상태를 숫자롭 반환하는데 이를 응답코드라고 함
(특히 우리가 많이 보는 404...는 웹 페이지를 찾을 수 없다는 것)

HTTP 응답에는 상태코드를 헤더에 추가하여 응답을 함

100-109: 메시지 정보
200-206: 요청 성공
300-305: 리다이렉션
400-415: 클라이언트 에러
500-505: 서버 에러

ex. 사용자가 요청 파라미터를 잘못 입력한 경우, 잘못된 파라미터로 인해 비즈니스 로직에서 에러가 발생했다고 하여 500 코드 반환하는 게 아니고! 사용자가 잘못 입력한 거니까 403 코드 반환

 

4. HTTP Method
클라이언트가 서버로 요청을 할 때, 어떠한 목적을 갖는 행위인지 HTTP 메서드에 명시한다.

GET: 서버에게 리소스를 달라는 요청(조회)
HEAD: 정확히 GET과 같지만, 서버는 응답으로 엔티티 본문 반환없이 헤더만을 반환. 클라이언트는 리소스를 가져올 필요없이 헤더만을 통해 정보를 얻을 수 있다.
PUT: 서버가 요청의 본문을 갖고 요청 URI의 이름대로 새 문서를 만들거나, 이미 URL가 존재한다면 요청 본문을 변경할 때 사용 (수정)
POST: 서버에 입력 데이터를 전송하며 요청 엔티티 본문에 데이터를 넣어 서버에 전송 (삽입)
DELETE: 서버에서 요청 URI 리소스를 삭제하도록 요청한다 (삭제)
클라이언트는 항상 삭제된다고 생각하지만, 서버에서는 이 요청을 무시할 수도 있다
TRACE: 클라이언트와 목적지 서버 사이에 있는 모든 HTTP 애플리케이션의 요청/응답 연쇄를 따라가면서 자신이 보낸 메시지의 이상 유무를 파악. 서버는 응답 메시지의 본문에 자신이 받은 요청 메시지를 넣어 응답하며, 주로 진단을 위해 사용한다.
OPTIONS: 서버에게 특정 리소스가 어떤 메소드를 지원하는지 물어볼 수 있다.

 

 

5. REST와 RESTful API, HTTP Method
1) REST
: 웹 초기에 웹을 무너뜨리지 않고 어덯게 HTTP 프로토콜을 발전시킬 수 있을까에 대한 고민으로 시작된 아키텍쳐.
REST API는 REST 아키텍쳐를 따르는 API
대부분의 API는 HTTP만 잘 따라도 어느정도 REST를 만족하는데, 이를 RESTful이라고 표현함.

그럼 REST를 만족하기 위해서는 어떤 특성들이 필요한가
특성들 중 uniform interface에서 제약조건 self-descriptive messages, HATEOAS가 있다

self-descriptive message
: 메세지 자체만으로 스스로를 설명할 수 있어야 한다.
HATEOAS
: 애플리케이션의 상태는 하이퍼링크를 통해 전이되어야 한다.


Restful API

ex Restful하지 않은 URI를 Restful 하게 바꿔보자. 
-게시글 조회
http://example.com/showPost
-게시글 추가
http://example.com/addPost

다음은 HTTP Method를 이용한 Restful API이다.
-게시글 조회
http://example.com/post
HTTP 메서드: GET
-게시글 추가
http://example.com/post
HTTP 메서드: POST
이렇게 Restful API로 설계하면 URI 매핑이 깔끔해지고 의미도 명확해진다는 장점이 있음



6. 헤더
HTTP 상에서 클라이언트와 서버는 데이터를 패킷 단위로 잘게 쪼개서 통신을 한다.
데이터 전송 단위인 패킷에는 요청/응답에 대한 메시지가 담겨 있다.

패킷의 구조
: 시작라인 / 헤더 / 본문

특히 헤더에는 패킷에 대한 많은 정보를 담고 있고 그 정보의 종류중 몇가지는 다음과 같음

Date: 메시지가 언제 만들어졌는지
Via: 메시지가 어떤 프락시를 거쳐왔는지
client-IP 클라이언트가 실행된 컴퓨터의 IP
Accept: 서버가 보내도 되는 미디어의 종류
Accept-charset: 서버가 보내도 되는 문자열셋
if-Modified-since: 주어진 날짜 이후에 리소스가 변경되지 않았다면 요청을 제한함
Authorization: 서버에게 제공하는 인증 자체에 대한 정보
Cookie: 쿠키 정보
Age: 응답이 얼마나 오래 걸렸는지
Server: 서버 정보
Allow: 현재 엔티티에 대해 수행될 수 있는 요청 메서드 목록
Content-Encoding: 본문에 적용된 인코딩
Content-type: 본문의 내용이 어떤 형식인지 (텍스트, 이미지 등)

 

 

 

참고

https://victorydntmd.tistory.com/286

https://www.youtube.com/watch?v=RP_f5dMoHFc