1. REST API
Representational State Transfer
🔧 REST API 탄생 배경
빵긋
- 2000년에 Roy Fielding의 박사학위 논문으로 발표되었다. 로이 필딩은 HTTP 사양의 주요 저자 중 한명이다. 그는 REST를 개발할 당시 "웹의 구조를 서술하는 비공식 문서들과 두 개의 소개 형식의 논문 등이 있었으나 실제 웹 구현이 너무 빨라 이미 구식이 되어버린 경우가 많았다", "그 당시 이미 캐시와 프록시 등이 웹에는 존재했으나 이에 대해 인식하는 표준은 없다시피 했다" 라고 했으며 웹에 대한 새로운 표준, 확장이 필요하다고 주장했다. HTTP 설계의 우수성에 비해 제대로 사용되어지지 못하는 모습에 안타까워 했다고 한다.
🔧 REST API 설계 목표
1. 컴포넌트 간의 유연한 상호 연동성 확보
- 상호 연동성은 서로 상이한 컴포넌트 들을 쉽게 연결할 수 있는 성질을 의미한다. 두개이상의 컴포넌트들을 결합함으로써 작업을 더 효율적으로 수행하도록 하는데 목적이 있다.
- REST는 HTTP, URI기반인데 HTTP와 URI 모두 표준이며 직관적으로 사용이 가능하며 어디서든 동일하게 작동되는 것을 보장할 수 있다.
2. 범용 인터페이스
- 상호연동성과 비슷하게 REST의 기반인 HTTP와 URI는 표준으로 어디서든지 사용가능한 범용 인터페이스를 제공한다.
- 개발자는 비즈니스 로직만 고민하면 된다.
3. 각 컴포넌트들의 독립적인 배포
- 각 컴포넌트들과의 독립적인 배포의 의미는 다른 컴포넌트와 독립적으로 개발할 수 있다는 것을 의미한다.
- 규격에 맞추어 개발했다면 다른 컴포넌트가 추가되어도 연동에 걱정할 필요가 없다.
4. 지연 감소, 보안 강화, 레거시 시스템을 캡슐화하는 중간 컴포넌트로의 역할
- 클라이언트는 엔드 서버에 직접 연결할 필요 없이 서비스를 이용할 수 있다. REST 서버가 클라이언트와 엔드 서버 중간에서 중계 역할을 할 수 있기 때문이다.
- 이러한 중계 서버로 활용하면 로드 밸런싱, 공유 메모리 등을 이용해 확장성/성능을 향상 시킬 수 있으며 보안 정책을 적용하기에도 용이하다.
🔧 REST API?
- API 시스템을 구현하기 위한 아키텍처 중에 가장 널리 사용되는 형식
엔드포인트 아키텍처 시스템 ex) Graphql, SOAP, GRPC, REST ... etc - 웹상에서 사용되는 여러 리소스를 HTTP URI로 표현하고 그 리소스에 대한 행위(CRUD)를 HTTP Method(POST, GET, PUT, DELETE...)로 정의하는 방법론.
- 웹의 모든 자원에 고유한 HTTP URI를 부여한다.
- 분산 하이퍼미디어 시스템을 위한 소프트웨어 개발 아키텍처의 한 형식.
- 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에 웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일이다.
🔧 REST의 구성
1. Resource(자원) - URL
- 자원은 Server에 저장되며 모든 자원에 고유한 ID가 존재한다.
- 자원을 구별하는 ID는
/products/product-id/1과 같은 HTTP URI다.
2. Verb(행위) - Http Method
- HTTP 프로토콜의 Method(POST, GET, PUT, DELETE...) 사용.
3. Representation(표현) - Payload
- Client가 자원의 상태에 대한 조작을 요청하면 Server는 이에 대한 적절한 응답(Representation)을 보낸다.
- REST에서 하나의 자원은 JSON, XML, TEXT, RSS등 여러 형태의 Representation으로 나타낼 수 있다.
(JSON으로 주고 받는 것이 대부분)
🔧 REST의 특징
1. Client/Server 구조
- Client는 유저와 관련된 처리를, Server는 REST API를 제공함으로써 각각의 역할이 확실히 구분되고 일괄적 인터페이스로 분리되어 작동할 수 있게 한다.
- 상호 의존성이 감소한다.
2. Stateless
- REST는 HTTP의 특성을 이용하기에 무상태성을 가진다.
- 들어온 요청에 대한 처리만 해주면 되므로 구현이 쉽고 단순해진다.
3. Cacheable
- 캐시 사용을 통해 응답시간이 빨라지고 REST server 트랜잭션이 발생하지 않기 때문에 전체 응답시간, 성능, 서버의 자원 이용률을 향상 시킬 수 있다.
4. Self-Descriptiveness
- JSON을 이용한 메시지 포맷을 이용하여 직관적으로 이해할 수 있고 REST API 메시지 만으로 그 요청이 어떤 행위를 하게 되는지 알 수 있다.
5. Layered System
- Client와 Server가 분리되어 있기 때문에 중간에 프록시 서버, 암호화 계층 등 중간 매체를 사용할 수 있어 자유도가 높아진다.
6. Uniform Interface
- Uniform Interface는 HTTP 표준에만 따른다면 모든 플랫폼에서 사용가능하며, URI로 지정한 리소스에 대한 조작을 가능하게 하는 아키텍쳐 스타일을 말한다.
- URI로 지정한 자원에 대한 조작을 통일되고 한정적 인터페이스로 수행한다.
- 특정 언어나 기술에 종속되지 않는다.
❗️ REST 규칙
1. 슬래시 구분자(/)는 계층 관계를 나타내는데 사용한다.
2. URI 마지막 문자로 /를 사용하지 않는다.
- URI가 다르다는 것은 리소스가 다르다는 것을 의미하므로
/가 포함되면 다른 리소스를 의미하게 된다.
3. 하이픈(-)은 URI 가독성을 높이는데 사용한다.
4. 언더바(_)는 URI에 사용하지 않는다.
5. URI 경로는 소문자로 표현한다.
6. 파일 확장자는 URI에 포함하지 않는다.
- 대신 Accept Header를 사용한다.
ex) GET :http://127.0.0.1/kidsney/products/2/Accept: image/jpg
7. 리소스간 연관 관계 표현
- 리소스명/리소스ID/관계가 있는 다른 리소스명
ex) GET :http://127.0.0.1/kidsney/users/2/orders
2. RESTful API
🔧 RESTful API?
- HTTP와 URI 기반으로 자원에 접근할 수 있도록 제공하는 어플리케이션 개발 인터페이스.
- HTTP 메소드와 URI만으로 인터넷에 자료를 CRUD할 수 있다.
- REST API를 제공하는 웹 서비스를 RESTful하다고 할 수 있다.
- RESTful은 REST를 REST답게 사용하기 위한 방법으로 누군가 공식적으로 발표한 것은 아니다.(표준규약X)
🔧 RESTful API 사용 배경
- RESTful API를 개발하는 가장 큰 이유는 Client Side를 정형화된 플랫폼이 아닌, 모바일, PC, 어플리케이션 등 플랫폼에 제약을 두지 않기로 목표했기 때문이다.
- 최근의 서비스의 개발 흐름은 멀티 플랫폼, 멀티 디바이스를 목표로 한다. 이전과는 달리 최근의 서버 프로그램은 여러 웹 브라우저, iOS, Android 어플리케이션의 통신에도 대응할 수 있어야 한다.
- 플랫폼에 맞추어 새로운 서버를 만드는 수고를 들이지 않기 위해 범용성을 보장하는 서버 디자인이 필요하게 되었다.
🔧 RESTful API 개발 원칙
1. 자원을 식별할 수 있어야 한다.
- URL 만으로 내가 어떤 자원을 제어하려고 하는지 알 수 있어야 한다.
- 자원의 위치는 물론 자원의 종류까지 알 수 있어야 한다.
- Server가 제공하는 정보는 JSON이나 XML 형태로 HTTP body에 포함되어 전송 시킨다.
2. 행위는 명시적이어야 한다.
- REST는 아키텍쳐 혹은 방법론과 비슷하다. 때문에 강제적이지 않으며 기존의 웹 서비스 처럼 GET을 이용해 UPDATE, DELETE를 해도 상관 없다.
- 하지만 REST 아키텍처에는 부합하지 않으므로 RESTful 하다고는 할 수 없다.
3. 자기 서술적이어야 한다.
- 데이터에 대한 메타정보만 가지고 어떤 종류의 데이터인지, 데이터를 위해 어떤 어플리케이션을 실행해야 하는지 알 수 있어야 한다.
- 즉, 데이터 처리를 위한 정보를 얻기 위해 데이터 원본을 읽어야 한다면 자기 서술적이지 못하다.
4. HATEOAS(Hypermedia As The Engine Of Application State)
- 클라이언트 요청에 대해 응답을 할 때, 추가적인 정보를 제공하는 링크를 포함할 수 있어야 한다.
- REST는 독립적으로 컴포넌트들을 손쉽게 연결하기 위한 목적으로도 사용된다. 따라서 서로 다른 컴포넌트들을 유연하게 연결하기 위해서 느슨한 연결을 만들어줄 필요가 있다.
이 때 사용되는 것이 링크이다. 서버는 클라이언트 응용 어플리케이션에 하이퍼 링크를 제공한다. - 클라이언트는 이 하이퍼 링크를 통해 전체 네트워크와 연겨로디며 HATEOAS는 서버가 독립적으로 진화할 수 있도록 서버와 서버, 서버와 클라이언트를 분리할 수 있게 한다.
3. REST의 단점
- REST는 Point-to-Point 통신모델을 기본으로 한다. 따라서 서버와 클라이언트가 연결을 맺고 상호작용해야하는 어플리케이션 개발에는 적절치 않다.
- REST는 URI, HTTP를 이용한 아키텍처링 방법에 대한 내용만을 가지고 있다. 보안과 통신규약 정책 같은 것은 다루지 않는다. 따라서 개발자는 통신과 정책에 대한 설계와 구현을 도맡아 진행해야 한다.
- HTTP에 상당히 의존적이다. REST는 설계 원리이기 때문에 HTTP와는 상관없이 다른 프로토콜에서도 구현할 수 있지만 자연스러운 개발은 힘들다. 다만 REST를 사용하는 이유가 대부분의 서비스가 웹으로 통합되는 현실이기 때문에 큰 단점은 아니게 되었다.
- CRUD 4가지 메소드만 제공한다.
- 표준 규약이 아니기 때문에 안티패턴으로 작성되는 경우가 많다.
4. 참고
- 오늘날 대부분의 REST API는 사실 REST를 엄격하게 따르지 않는다.
- REST의 제약조건 중에 특히 Self-descriptive와 HATEOAS를 잘 만족하지 못한다.
- REST는 긴 시간에 걸쳐 진화하는 웹 어플리케이션을 위한 것이다.
- REST를 따를 것인지 API를 설계하는 이들이 스스로 판단하여 결정해야한다.
- REST를 따르겠다면, Self-descriptive와 HATEOAS를 만족시켜야 한다.
Self-descriptive는 custom media type나 profile link relation등으로 만족시킬수 있고,
HATEOAS는 HTTP 헤더나 본문에 링크를 담아 만족시킬 수 있다. - REST를 따르지 않겠다면, REST를 만족하지 않는 REST API를 뭐라 부를지 결정해야 할 것이다.
비진