[TIL] Network-HTTP-REST API

JIEUN YANG·2022년 10월 15일

REST API 아키텍처 이전의 개발환경은 서버에서 화면단을 직접 호출하는 방식이었다.
그러다보니, 웹브라우저 앱 등 각각의 플랫폼마다 서버를 하나씩 만들어야만 했다.
이러한 비효율성 때문에 2000년도에 로이필딩이 Web의 장점을 최대한 활용할 수 있는 Architecture로 REST 를 발표했고 하나의 서버로 여러 플랫폼(웹 브라우저, 앱, 태블릿, 스마트워치)의 클라이언트와 서버를 연동할 수 있게 되었다.

REST API

REST(Representational State Transfer)란, 소프트웨어 프로그램의 한 아키텍처로

URI로 자원을 명시하고, http method을 통해 자원의 CRUD 가 실행된다.
HTTP 프로토콜에 의존적이며 클라이언트와 서버 중간에서 자원의 이동 및 변경을 담당한다.

REST API 이점

캐싱을 구현할 수 있으며 이는 데이터 접근 속도를 빠르게 해준다.
HTTP의 웹표준을 그대로 사용하기 때문에 웹의 인프라가 제공하는 caching 기능을 적용할 수 있다.
캐싱은 응답값의 복사본을 저장하고 있다가 이를 반환하는 프로세스로, 클라이언트가 요청한 모든 서비스의 데이터를 서버까지 도달하지 않고 캐시 저장소의 데이터로 응답한다. 따라서 서버의 과부하를 방지하고 리소스의 응답 속도가 향상된다.
무상태성의 특성으로 서버 처리방식이 일관적이고 서버의 부담이 줄어든다.
REST 아키텍처에서 서버는 클라이언트와 독립적으로 통신한다. 즉 이전 요청들을 기억하거나 제어하지 않기 때문에 연결이 해제되고 클라이언트에서 동일한 데이터를 원한다고 해도 또 다시 서버연결이 필요한 것이다. 따라서 상태를 저장해야할 때보다 서버의 부담을 감소시킨다.
클라이언트와 서버가 명확하게 구분되어 프록시 서버, 암호화 등의 중간매체의 계층화가 가능하다.
클라이언트와 서버 중간에 존재하는 REST API는 암호계층, 캐싱계층, 로드-밸런딩 계층 등 여러개의 서버가 존재할 수 있고 각각은 요청이나 응답값에 영향을 끼치지 않는다.

REST API 작동원리

클라이언트에서 서버로 요청을 보낸다.

URL, method방식, 데이터 규격 등 API 문서에 맞게 요청 형식을 지정해야 한다.
클라이언트 요청에는 고유 리소스 식별자와 메서드, HTTP 헤더를 포함하고 있다.
엔드포인트라고 불리는 URL(Uniform Resource Locator)을 통해 각 리소스를 구별하고, 요청 시 어떤 작업을 수행해야 하는지 HTTP의 메서드로 알려준다. 메서드는 크게 4가지(GET, POST, PUT, DELETE) 로 구성된다.

GET : 데이터를 조회할 때 사용되며 캐싱의 대상이 된다 -> 데이터 READ
POST : 서버에 데이터를 전송할 때 사용된다 -> 데이터 CREATE
PUT : 서버의 기존 리소스를 변경할 때 사용된다 -> 데이터 UPDATE
DELETE : 리소스를 제거할 때 사용된다. -> 데이터 DELETE

서버에서는 요청을 보낸 클라이언트가 수행 권한이 있는지 확인한다.

이를 인증 프로세스라고 하며, 클라이언트는 4가지의 방법을 통해 신원을 증명할 수 있다.

기본인증 : 요청 헤더에 사용자 이름 및 암호를 넣어서 전송한다. 보안을 위해 base64로 인코딩하여 이름-암호의 페어를 64자의 세트로 변환한다.
전달자 인증 : bearer 인증이라고도 하며 암호화된 문자열인 토큰을 통해 엑세스를 제어하는 방식이다. 클라이언트에서 리소스에 액세스 할 때 요청 헤더에 넣어서 전송하면 서버는 해당 토큰이 특정 리소스에 대한 접근 권한 유무를 판단한다.
API 키 : 서버가 고유한 KEY 값을 클라이언트에 할당한다. 클라이언트에서 API 키를 사용하여 검증 작업을 거치며, 요청 시마다 전송해야 하기 때문에 보안에 취약하다.
OAuth : 암호와 토큰을 결합한 형태로 안전한 로그인 액세스를 보장한다. 서버에서는 암호를 요청한 뒤 토큰를 추가로 확인하는 순서를 거친다.