HTTP
모든 것을 HTTP에 담아서 전송한다. 서버간에 데이터 주고 받을때도 사용.
HTTP 1.1 가장 많이 사용, 가장 중요한 버전
HTTTP 2, 3 은 성능 개선에 초점이 맞춰져있다.
특징
- 클라이언트 서버 구조
- 무상태 프로토콜(Stateless), 비연결성
- HTTP 메세지
- 단순함, 확장 가능
클라이언트 서버구조
클라이언트는 HTTP메세지를 담아서 서버로 자원을 Request(요청) 하고 대기한다.
서버는 HTTP메세지를 받아서 처리한 후 클라이언트로 Response 한다.
무상태 프로토콜(Stateful, Stateless)
Stateful (상태 유지)
Stateful은 서버가 상태를 유지하는 것이다.
항상 같은 서버가 유지되어야 한다. 서버가 바뀌면 안된다?
Stateless (무상태)
Stateless는 서버가 상태를 유지하지 않는다.
응답 서버를 쉽게 바꿀 수 있다. → 무한한 서버 증설 가능
한계
모든 것을 무상태로 설계할 수 있는 경우도 있고 없는 경우도 있다.
로그인 같은경우 상태유지가 필요하지만 쿠키와 세션을 이용해여 상태유지를 시킨다.
상태 유지는 최소한만 사용한다!
비 연결성
HTTP는 기본이 연결을 유지하지 않는 모델이다.
단점
TCP/IP 연결을 새로 맺어야함(3 way handshake 시간 추가) → 지금은 HTTP 지속 연결(Persistent Connections)로 문제 해결
HTTP 메세지
HTTP 헤더
용도 - HTTP 전송에 필요한 모든 부가정보 ex) 메세지 바디 내용, 크기, 인증, 압축, 캐시 정보, .. 등
메세지 바디 빼고 필요한 메타 데이터 전부 다 들어있음
필요시 임의의 헤더 추가 기능
바디
용도 - 실제 전송할 데이터
HTML, 문서, 이미지, 영상, JSON 등등
HTTP 메서드
리소스와 행위를 분리
API 설계에서 가장 중요한 것은 리소스를 식별하는 것
- URI는 리소스만 식별
- 리소스와 해당 리소스를 대상으로 하는 행위를 분리
- 리소스: 회원
- 행위: 조회, 등록, 삭제, 변경
메서드
GET
- 리소스 조회
- 서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 스트링) 을 통해 전달한다.
- 메시지 바디를 사용해서 데이터 전달이 가능하지만, 지원하지 않는 곳이 많아 권장하지 않는다.
POST
- 주로 새 리소스 생성(등록) 할 때 사용한다.
- 요청 데이터 처리 (시스템의 큰 변화가 생기는 프로세스의 상태가 변경되는 경우)
- 애매하면 다 POST (POST는 다 할 수 있다.)
PUT
- 리소스를 완전히 대체한다!
- POST와 차이점 URI를 정확히 알고있다? ex) members/1
PATCH
- 리소스의 일부분을 변경한다.
DELETE
- 리소스를 삭제할 때 사용한다.
안전
리스소가 변경되지않으면 안전하다. → GET
멱등
동일한 클라이언트가 같은 요청을 여러번해도 결과가 같으면 ‘멱등하다’ 라고 표현한다. → f(f(x)) = f(x)
POST는 멱등하지 않다. ex) 결제 2번..
캐시가능
GET, HEAD 만 응답 결과 리소스를(이미지 등) 캐시할 때 사용한다.
POST와 PATCH는 캐시 가능하지만 구현하기 어렵다.
