1. RESTful API란?
1) API의 정의와 역할
API는 Application Programming Interface의 약자로, 서로 다른 프로그램 또는 시스템 사이의
상호작용을 위해 정해놓은 규칙(인터페이스)을 의미한다.
UI가 사용자와 프로그램 사이의 중개자라면 API는 프로그램과 프로그램 사이의 중개자로서,
주로 프로그램의 기능을 간접적으로 외부에 제공하고자 할 때 정의하여 사용한다.
API 중에서도 네트워크 통신을 사용하는 웹 API는 양쪽 프로그램을 서버와 클라이언트로 나누고
중간에서 게이트웨이 역할을 한다.
웹 API 용어
리소스(Resource): 이미지, 동영상, 텍스트, 사운드 등 모든 유형의 데이터
클라이언트(Client): 리소스에 접근을 요청하는 사용자 또는 프로그램
서버(Server): 리소스를 제공하는 프로그램 또는 시스템
2) REST의 개념과 의미
REST는 소프트웨어 아키텍처의 일종으로 복잡한 네트워크 통신을 관리하기 위해 만들어졌다.
REST는 Representational State Transfer의 약자이며
(리소스에 대한) 표현을 통해 상태(특정 시점의 데이터)를 전송한다는 의미이다.
REST 아키텍처로 설계된 API를 REST API 또는 RESTful API라고 부르며,
일반적으로 REST(ful) API는 웹 API를 의미한다.
2. REST 아키텍처 설계 원칙
REST 아키텍처를 설계하기 위한 몇 가지 원칙이 존재한다.
1) 균일한 인터페이스 (Uniform Interface)
REST 아키텍처의 가장 기본적인 원칙으로서
이 원칙을 지키면 한정되고 통일된 인터페이스를 사용해 데이터를 조작할 수 있다.
따라서 HTML, JSON, XML과 같은 표준 형식으로 리소스를 표현하고 전송한다.
해당 원칙을 준수하기 위한 4가지 제약이 존재한다.
A) 리소스 식별 (identification of resources)
클라이언트의 요청은 리소스를 식별하고 구분할 수 있어야 한다.
일반적으로 URI(Uniform Resource Identifier)를 사용한다.
B) 표현을 통한 리소스 조작 (modification of resource through representation)
리소스 표현은 리소스를 조작(변경, 삭제 등)하기 위한 충분한 정보를 가져야 한다.
위 두가지 제약으로 인해 REST 아키텍처는 URI를 사용하여 리소스를 지정하고
HTTP 메서드로 리소스에 대한 행위를 나타낸다.
C) 자기 서술적 메세지 (self-descriptive message)
서버는 클라이언트가 리소스를 적절하게 처리하고 사용할 수 있도록
그 방법에 대한 데이터를 메시지에 포함하여 전송해야 한다.
그렇게 함으로써 메세지는 그 자체로 설명될 수 있어야 한다는 의미이다.
잘 지켜지지 않는 제약 중 하나로, 일반적으로 이 제약을 준수하기 위해서
메세지에 HTTP 헤더 또는 응답 코드를 포함시키는데
API 문서에 대한 링크를 포함시킨다면, 만약 데이터가 변경되더라도
메시지의 문서 링크를 통해 바로 파악이 가능하여 제약을 확실하게 준수할 수 있다.
D) HATEOAS (hypermedia as the engine of application state)
서버는 클라이언트가 작업을 완료하기 위해 필요한 추가적인 리소스를
하이퍼미디어로 전송해야 한다.
서버와 클라이언트를 완전히 분리되게 만드는 제약조건으로,
클라이언트는 수신한 하이퍼미디어(링크)를 통해 동적으로 링크를 변경하거나
쉽게 상태 전이가 가능하다.
예를 들어 어떤 리소스의 URI가 변경됐을 때 클라이언트는 하이퍼미디어를 통해
내부 코드를 변경하지 않고 동일한 리소스에 동적으로 접근할 수 있다.
이로 인해 클라이언트와 서버가 서로의 변경에 영향을 받지 않으므로 완전 분리가 일어난다.
2) 무상태 (stateless)
서버는 과거(이전)의 요청과 상관없이 모든 요청을 독립적으로 수행해야하며,
요청을 수행하기 위해 저장된 컨텍스트를 사용해선 안된다.
따라서 모든 요청은 서버가 요청을 완전히 이해하고 수행할 수 있도록
충분한 정보를 가져야 한다.
3) 계층형 시스템 (layered system)
아키텍처를 보안, 비즈니스 로직처럼 여러 계층으로 나누어 설계할 수 있다.
클라이언트는 서버가 아닌 다른 계층과 통신할 수 있으며,
서버는 다른 서버에게 요청을 전달할 수 있지만
그러한 계층 구조는 클라이언트에게 보이지 않는다.
4) 캐시 가능성 (cachable)
서버의 응답 시간 단축을 위해 응답을 클라이언트에 저장하는 캐싱을 지원해야 한다.
이를 위해 E-Tag 등의 방법을 사용하여 캐시 가능 여부를 응답에 포함한다.
5) 코드 온 디멘드 (code-on-demand)
클라이언트의 필요에 따라 서버는 프로그래밍 코드를 전송하여
클라이언트의 기능을 일시적으로 확장할 수 있다.
이 원칙을 준수하면 클라이언트에 구현할 기능을 줄임으로써 클라이언트를 단순화할 수 있다.
3. REST 아키텍처의 장단점
1) 장점
A) 확장성
REST 아키텍처는 서버-클라이언트 상호작용의 최적화가 이루어져 확장에 용이하다.
무상태 원칙으로 인해 서버는 클라이언트의 요청을 저장하지 않고
캐시 가능성으로 서버-클라이언트 상호작용을 일부분 제거하기 때문에 서버 부하를 감소시킨다.
결과적으로 성능 저하를 일으키는 통신 병목 현상을 감소시켜 확장성을 높인다.
B) 유연성
REST 아키텍처는 서버와 클라이언트가 완전히 분리되어 서로 독립적이기 때문에
각 프로그램에 대한 변경이 서로에게 영향을 주지 않아서 매우 유연하다.
또한 계층형 시스템 원칙으로 서버의 구성 요소를 여러 계층으로 나누면
다른 계층에 영향을 주지 않고 변경이 가능하여 유연하다.
C) 독립성
REST 아키텍처는 사용되는 기술에 독립적이기 때문에 설계와 관계없이
다양한 프로그래밍 언어와 플랫폼으로 서버와 클라이언트를 작성할 수 있다.
또한 통신에 영향을 주지 않고도 각 프로그램의 기술을 변경할 수 있다.
2) 단점
A) 오버패칭과 언더패칭
고정적인 데이터 구조를 전송하는 엔드포인트의 특성으로 인해
클라이언트에서 필요한 것보다 많은 데이터를 전송하는 오버패칭과
필요한 데이터를 받기 위해 여러번의 API 호출을 해야하는 언더패칭 문제가 발생한다.
B) 엔드포인트 증가
서비스가 복잡해 질 수록 클라이언트에서 요청하는 데이터 역시 증가하므로
관리해야하는 엔드포인트가 증가한다.
이러한 단점을 해결하기 위해서 GraphQL을 사용할 수 있다.
GraphQL은 단일 엔드포인트를 사용해 클라이언트에서 필요한 데이터를 지정하는
선언적 데이터 패칭이 가능하여 REST보다 효율적인 새로운 API 표준으로 자리잡고 있다.
참고 문서
'CS' 카테고리의 다른 글
| 아키텍처 패턴에 대하여 (MVC, MVP, MVVM) (0) | 2023.02.10 |
|---|---|
| 함수형 프로그래밍에 대하여 (1) | 2023.02.06 |
| Git과 Github에 대하여 (feat. Merge VS Rebase) (0) | 2023.02.04 |
| 애자일(Agile)에 대하여 (0) | 2023.01.27 |
| 객체 지향 프로그래밍(OOP)에 대하여 (0) | 2023.01.20 |