REST API
REST(Representational State Transfer, 자원을 이름으로 구분하여 해당 자원의 상태를 주고받는 것)를 기반으로 만들어진 API이다.
REST 구성요소
- 자원 (Resource) : HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고,
- 행위 (Verb) : HTTP Method(POST, GET, PUT, DELETE, PATCH 등)를 통해
- 표현 (Representation of Resource) : 해당 자원(URI)에 대한 처리를 하는 것이다.
REST API의 설계 규칙을 올바르게 지킨 시스템을 RESTful 하다고 할 수 있다.
REST API는 메시지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악할 수 있다.
서버와 클라이언트의 역할을 명확하게 분리한다.
- URI는 동사보다는 명사를, 대문자보다는 소문자를 사용
- 행위를 포함하지 않는다.
- 언더바(_)보다는 하이푼(-)을 사용
- URI에 작성되는 영어를 복수형으로 작성
HTTP 특징
- 클라이언트-서버 구조(Request - Response) : 클라이언트는 서버에 요청을 보내고, 서버는 요청에 대한 결과를 만들어 응답한다.
- 단순한 HTTP 메시지로 통신하여 확장 가능한 기술
- 무상태 프로토콜(stateless)
서버가 클라이언트의 상태를 보존하지 않기 때문에 서버를 쉽게 바꿀 수 있어 확장성이 높다.
ex) 점원,고객 거래 중 점원이 바뀌는 예시
상태유지 - 노트북 얼마?, 2개 구매하겠습니다, 신용카드로 구매하겠습니다. → 중간에 점원이 바뀌면 안된다.
무상태 - 노트북 얼마?, 노트북 2개 구매하겠습니다. 노트북 2개 신용카드로 구매하겠습니다.
무상태는 고객이 필요한 데이터를 점원에게 모두 넘기기때문에 점원이 바뀌어도 상관없다.
→ 갑자기 고객이 증가해도 점원을 대거 투입할 수 있다. → 갑자기 트래픽이 증가해도 서버를 대거 투입가능
하지만, 로그인 처럼 상태를 유지해야 하는 경우 브라우저 쿠키와 서버 세션등을 사용해서 상태를 유지하는데 최소한만 사용해야 한다. - 비연결성 : 데이터 통신이 끝나면 연결을 바로 끊어서 응답이 빠르고 서버 자원을 효율적으로 사용할 수 있다.
But, 연결을 새로 맺는데 필요한 시간이 필요하고 HTML,CSS,이미지 등의 많은 자원도 함께 필요하다.
→ HTTP 지속 연결(Persistent Connections)로 문제 해결
HTTP 헤더
- Content-Type : 표현 데이터의 양식
- Host : 요청한 호스트 정보(도메인)
- Location : 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동
- Allow : 허용 가능한 HTTP 메서드
- Authorization : 클라이언트 인증 정보를 서버에 전달
(인증 토큰을 서버로 전달 (bearer token 으로 JWT 사용)) - Set-Cookie : 서버에서 클라이언트로 쿠키 전달(응답)
캐시 관련
- cache-control : max-age : 캐시가 유효한 시간을 설정하여 응답결과를 브라우저 캐시에 저장한다.
캐시 유효시간이 초과해서 서버에 다시 요청했을때
- 서버에서 기존 데이터를 변경한 상황 : 다시 요청하여 데이터를 캐시에 저장한다.
- 서버에서 기존 데이터를 변경하지 않은 상황
캐시의 데이터와 서버의 데이터가 같다는 사실을 확인되면, 저장해 두었던 캐시를 재사용한다.
- Last-Modified : 데이터 최종 수정일을 가진다. 캐시에 데이터를 저장할 때 함께 저장한다.
- if-modified-since : 캐시가 가지고 있는 최종수정일
데이터의 최종 수정일과 캐시가 가진 최종 수정일이 같다면, 데이터가 변경되지 않은 것이므로
304(Not Modified)와 + 헤더 메타 정보만 응답(수정된 데이터가 없기 때문에 HTTP 바디가 없다!) 하여 캐시를 재사용한다.
HTTPS (Hyper Text Transfer Protocol Secure)
HTTP에 데이터 암호화가 추가된 프로토콜이다.
HTTPS는 대칭키 암호화 방식과 비대칭키 암호화 방식을 모두 사용하여 빠른 연산속도와 안전성을 가진다.
- 대칭키 암호화
- 클라이언트와 서버가 동일한 키를 사용해 암호화/복호화를 진행함
- 키가 노출되면 매우 위험하지만 연산 속도가 빠름
- 비대칭키 암호화 (공개키 방식)
- 1개의 쌍으로 구성된 공개키와 개인키를 암호화/복호화 하는데 사용함
- 키가 노출되어도 비교적 안전하지만 연산 속도가 느림
- 공개키로 암호화 - 개인키로만 복호화 가능 → 개인만 복호화 가능
개인키로 암호화 - 공개키로만 복호화 가능 → 내가 인증한 정보임을 알려 신뢰성을 보장할 수 있다.
HTTPS 동작 과정 (Hand-Shaking)
서버와 클라이언트간에 주고받는 데이터를 암호화 하기 위해 세션키를 교환한다.
데이터 교환간에 빠른 연산 속도를 위해 대칭키 암호화 방식을 사용한다.
처음 서버와 클라이언트가 연결을 성립하여 안전하게 세션키를 공유하는 과정에서 비대칭키가 사용된다.
- 클라이언트가 최초 연결 시도하면 서버는 인증서를 브라우저로 넘긴다.
- 브라우저는 인증서의 유효성을 검사하고 세션키를 발급한다.
- 브라우저는 서버의 공개키로 세션키를 암호화하여 서버로 전송한다.
- 서버는 암호화된 세션키를 복호화하여 세션키를 얻는다. (서버의 개인키로 세션키를 복호화)
- 클라이언트와 서버는 동일한 세션키로 (대칭키 방식) 데이터를 전달할 때 암호화/복호화를 진행한다.
왜 HTTPS Handshake 과정에서는 인증서를 사용하나요?
서버는 클라이언트와 세션키를 공유하기 위한 공개키를 생성해야 하는데, 일반적으로는 인증된 기관(Certificate Authority)에서 개인키로 암호화된 인증서를 발급받는다.
개인키로 암호화된 인증서는 CA에서 인증한 정보임을 알려 신뢰성을 보장받을 수 있다.
