[Other] REST API에 대해서

Byron·2021년 8월 5일

Other

목록 보기

7/13

REST API란?

REST API는 REST 아키텍쳐 스타일을 따르는 API를 말한다.
정보들이 주고받아지는 데 있어서 개발자들 사이에 널리 쓰이는 일종의 형식으로,
프로그래밍 언어나 프레임워크 / 소프트웨어 등 기술에 구애받지 않고,
정해진 폼에 맞춰서 기능들을 만들어 내면 된다.

REST?

REpresentational State Transfer

분산 하이퍼미디어 시스템(예: 웹)을 위한 아키텍쳐 스타일(제약조건의 집합)인데,
HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고
HTTP Method(POST, GET, PUT, DELETE)를 통해
해당 자원에 대한 CRUD Operation을 적용하는 방식이다.

=> Resource가 HTTP Method를 통해 Resource를 처리하도록 설계되었는가.

API?

Application Programming Interface: 응용 프로그램 프로그래밍 인터페이스

어플리케이션이 프로그래밍 된(혹은 되는) 인터페이스로,
지정된 형식(부 프로그램이나 프로토콜)으로 요청, 명령을 받을 수 있는 인터페이스 사양을 말한다.

REST를 구성하는 스타일(제약조건)

client-server: REST 서버는 API 제공, 클라이언트는 사용자 인증이나 컨텍스트(세션, 로그인 정보) 등을
직접 관리하는 구조로, 각각의 역할이 확실히 구분되는 것.
클라이언트와 서버에서 개발해야 할 내용이 명확해지고 서로 간 의존성이 줄어들게 된다.

stateless(무상태성): 작업을 위한 상태정보를 따로 저장하고 관리하지 않기에 무상태성을 띈다.
API 서버는 세션이나 쿠키 정보를 별도로 저장하고 관리하지 않고, 단순히 들어오는 요청만을 처리하면 된다.
서버에서 불필요한 정보를 관리하지 않아 구현이 단순해진다.

cacheable(캐시 가능): HTTP라는 기존 웹 표준을 그대로 사용하기 때문에, 웹에서 사용하는 기존 인프라를
그대로 활용할 수 있다. 따라서 HTTP가 가진 캐싱 기능을 적용할 수 있다.

layered system: REST 서버는 다중 계층으로 구성될 수 있으며 보안, 로드 밸런싱, 암호화 계층을 추가해
구조상의 유연성을 둘 수 있고 PROXY, 게이트웨이 같은 네트워크 기반의 중간매체를 사용할 수 있게 한다.

code-on-demand(optional): 서버에서 코드를 클라이언트로 보내서 실행할 수 있어야 한다
		          (ex_JavaScript)

**uniform interface**: HTTP 표준에만 따른다면 안드로이드/IOS 플랫폼이든, 
특정 언어나 기술에 종속되지 않고 모든 플랫폼에 사용할 수 있으며,
URI로 지정한 리소스에 대한 조작이 가능한 아키텍처 스타일

REST를 만족시키기 힘들게 하는 uniform interface의 제약조건 두 가지는 알아두자.

self-descriptive message > 메시지는 스스로를 설명해야 한다.
메시지를 봤을 때, 메시지의 내용으로 해석이 다 가능해야 한다는 것.

HATEOAS > 애플리케이션의 상태는 Hyperlink를 이용해 전이되어야 한다

이런 여러가지 REST의 제약조건을 따라 잘 작성된 API를 RESTful API라고 한다.

[출처] Youtube video_Day1, 2-2. 그런 REST API로 괜찮은가 中

REST의 목표?

구성 요소 상호작용의 규모 확장성(scalability of component interactions)
인터페이스의 범용성 (Generality of interfaces)
구성 요소의 독립적인 배포(Independent deployment of components)
중간적 구성요소를 이용한 응답 지연 감소, 보안 강화, 레거시 시스템 인캡슐레이션 
(Intermediary components to reduce latency, enforce security and encapsulate legacy systems)

등이 있다고 하는데, 나는 이해하기 쉽게
각 요청이 어떤 동작이나 정보를 위한 것인지를 그 요청의 모습 자체로 추론 가능하도록 하는 것이라고 생각하려고 한다.

REST의 장단점

장점: 
1. HTTP 프로토콜의 인프라를 그대로 사용하므로 REST API를 위한 별도의 인프라를 구축할 필요가 없음
2. HTTP 프로토콜의 표준을 최대한 활용하여 여러 추가적인 장점을 함께 가져갈 수 있게 해줌
3. HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능
4. Hypermedia API의 기본을 충실히 지키면서 범용성을 보장함
5. REST API 메시지가 의도하는 바를 명확하게 나타냄
6. 서버와 클라이언트의 역할을 명확하게 분리함

단점:
1. 표준 자체가 존재하지 않아 정의가 필요함
2. HTTP Method 형태가 제한적임(사용할 수 있는 메소드가 4가지에 준하니까)
3. 브라우저를 통해 테스트할 일이 많은 서비스라면, 쉽게 고칠 수 있는 URL보다 
   Header 정보의 값을 처리해야 하므로 전문성이 요구됨
4. 구형 브라우저에서 호환이 되지 않아 지원해주지 못하는 동작이 많음(익스플로러 등)