REST API : 클라이언트와 서버 간의 두 컴퓨터 시스템이 인터넷을 통해 정보를 안전하게 교환하기 위해 사용하는 인터페이스를 말한다.
API(애플리케이션 프로그래밍 인터페이스)는 애플리케이션이나 디바이스가 서로 간에 연결하여 통신할 수 있는 방법을 정의하는 규칙 세트이다.
REST API는 REST(REpresentational State Transfer) 아키텍처 스타일의 디자인 원칙을 준수하는 API이다. 이러한 이유로 REST API를 RESTful API라고도 한다.
REST란?
REST는 자원 기반의 구조 (ROA: Resource Oriented Architecture) 설계의 중심에 Resoure가 있고 HTTP Method를 통해 Resource를 처리하도록 설계된 아키텍쳐를 의미한다.
이 때 가장 중요한 규칙은 다음 두가지이다.
URI는 정보의 자원을 표현해야 한다
자원에 대한 행위는 HTTP Method (GET, POST, PUT, DELETE 등)으로 표현한다
여기서 자원은 문서, 사진, 그림, 데이터 등 소프트웨어가 관리하는 모든 것을 의미한다.
이러한 자원들을 HTTP URI(Uniform Resource Identifier)를 통해 명시해야 한다. 때문에 웹의 모든 자원에 고유한 ID인 HTTP URI 를 부여한다.
예를 들어 DB의 영화 정보가 자원일 때, /movies를 자원의 표현으로 정한다. ex) GET /movies/1
그리고 HTTP Method를 통해 해당 자원(URI)에 대한 'CRUD Operation'을 적용한다.
💡 CRUD Operation이란?
Create : 데이터 생성(POST)
Read : 데이터 조회(GET)
Update : 데이터 수정(PUT, PATCH)
Delete : 데이터 삭제(DELETE)
REST의 구성
자원(RESOURCE) - URI
모든 자원에 고유한 ID가 존재하고, 이 자원은 Server에 존재한다.
자원을 구별하는 ID는 ‘/groups/:group_id’와 같은 HTTP URI Client는 URI를 이용해서 자원을 지정하고 해당 자원의 상태(정보)에 대한 조작을 Server에 요청한다.
행위(Verb) - HTTP METHOD
HTTP 프로토콜의 Method를 사용한다. HTTP 프로토콜은 GET, POST, PUT, DELETE 와 같은 메서드를 제공한다.
표현(Representations)
Client가 자원의 상태(정보)에 대한 조작을 요청하면 Server는 이에 적절한 응답(Representation)을 보낸다.
REST에서 하나의 자원은 JSON, XML, TEXT, RSS 등 여러 형태의 응답을 받을 수 있다. JSON 혹은 XML를 통해 데이터를 주고 받는 것이 일반적이다.
REST의 특징
1) Uniform (유니폼 인터페이스)
Uniform Interface는 Http 표준에만 따른다면 모든 플랫폼에서 사용이 가능하며, URI로 지정한 리소스에 대한 조작을 가능하게 하는 아키텍쳐 스타일을 말한다
URI로 지정한 Resource에 대한 조작을 통일되고 한정적인 인터페이스로 수행한다.
즉, 특정 언어나 기술에 종속되지 않는다.
2) Stateless (무상태성)
REST는 HTTP의 특성을 이용하기 떄문에 무상태성을 갖는다.
즉 서버에서 어떤 작업을 하기 위해 상태정보(세션정보, 쿠키 등)를 기억할 필요가 없고 들어온 요청에 대해 처리만 해주면 되기 때문에 구현이 쉽고 단순해진다.
3) Cacheable (캐시 가능)
대량의 요청을 효율적으로 처리하기 위해 캐시가 요구되는데 HTTP라는 기존 웹표준을 사용하는 REST의 특징 덕분에 기본 웹에서 사용하는 인프라를 그대로 사용 가능하다.
REST에서도 캐시 사용을 통해 응답시간이 빨라지고 REST Server 트랜잭션이 발생하지 않기 때문에 전체 응답시간, 성능, 서버의 자원 이용률을 향상 시킬 수 있다.
4) Self-descriptiveness (자체 표현 구조)
JSON 등을 이용한 메시지 포멧을 이용하여 직관적으로 이해할 수 있고 REST API 메시지만으로 그 요청이 어떤 행위를 하는지 알 수 있다.
5) Client - Server 구조
클라이언트는 유저와 관련된 처리를, 서버는 REST API를 제공함으로써 각각의 역활이 확실하게 구분되고 일괄적인 인터페이스로 분리되어 작동할 수 있게 한다
REST Server: API를 제공하고 비지니스 로직 처리 및 저장을 책임진다.
Client: 사용자 인증이나 context (세션, 로그인 정보) 등을 직접 관리하고 책임진다.
서로 간 의존성이 줄어든다.
6) 계층형 구조
클라이언트와 서버가 분리되어 있기 때문에 중간에 프록시 서버, 암호화 계층 등 중간매체를 사용할 수 있어 자유도가 높다
REST의 장단점
장점
HTTP 프로토콜의 인프라를 그대로 사용하므로 REST API 사용을 위한 별도의 인프라를 구출할 필요가 없다.
REST는 기본적으로 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에 웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일이다.
HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다.
Hypermedia API의 기본을 충실히 지키면서 범용성을 보장한다.
REST API 메시지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악할 수 있다.
여러가지 서비스 디자인에서 생길 수 있는 문제를 최소화한다.
서버와 클라이언트의 역할을 명확하게 분리한다.
단점
표준이 존재하지 않는다.
HTTP Method 형태가 제한적이어서 사용할 수 있는 메소드가 4가지 밖에 없다.
브라우저를 통해 테스트할 일이 많은 서비스라면 쉽게 고칠 수 있는 URL보다 Header 값이 왠지 더 어렵게 느껴진다.
익스플로러와 같은 구형 브라우저가 아직 제대로 지원해주지 못하는 부분이 존재한다.
ex) PUT, DELETE를 사용하지 못하는 점
ex) pushState를 지원하지 않는 점
REST는 point-to-point 통신모델을 기본으로 한다. 따라서 서버와 클라이언트가 연결을 맺고 상호작용해야하는 어플리케이션의 개발에는 적당하지 않다.
REST는 URI, HTTP 이용한 아키텍처링 방법에 대한 내용만을 담고 있다. 보안과 통신규약 정책 같은 것은 전혀다루지 않는다. 따라서 개발자는 통신과 정책에 대한 설계와 구현을 도맡아서 진행해야 한다.
REST가 필요한 이유
최근의 서비스(애플리케이션)의 개발 흐름은 멀티 플랫폼, 멀티 디바이스 시대로 넘어와 있다. 단순히 하나의 브라우저만 지원하면 되었던 이전과는 달리, 최근의 서버 프로그램은 여러 웹 브라우저는 물론이며, 아이폰, 안드로이드 애플리케이션과의 통신에 대응할 수 있어야 한다.
따라서 플랫폼에 맞추어 새로운 서버를 만드는 수고를 들이지 않기 위해 범용적으로 사용성을 보장하는 서버 디자인이 필요하게 되었었다.
그래서 다시 REST API란?
REST API : REST 기반으로 서비스 API를 구현한 것
최근 OpenAPI(누구나 사용할 수 있도록 공개된 API: 구글 맵, 공공 데이터 등), 마이크로 서비스(하나의 큰 애플리케이션을 여러 개의 작은 애플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍처) 등을 제공하는 업체 대부분은 REST API를 제공한다.
이 API는 항상 메뉴얼도 힘께 제공해야 한다. URI를 모르면 클라이언트는 사용할 수 없기 때문이다.
💡 REST API 설계 규칙
1) 명사, 소문자 => 동사x
2) 명사는 복수형
3) URI 마지막은 / 포함x
4) URI는 언더바x 하이픈 사용 -
5) 파일의 확장자를 표시x
RESTful
1. RESTful 하다?
REST 원리를 따르는 시스템은 RESTful이란 용어로 지칭하므로 ‘REST API’를 제공하는 웹 서비스를 ‘RESTful’하다고 할 수 있다.
2. RESTful의 목적
이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것이 목적이다.
RESTful한 API를 구현하는 근본적인 목적이 성능 향상에 있는 것이 아니라 '일관적인 컨벤션을 통한 API의 이해도 및 호환성을 높이는 것'이 주 동기이니, 성능이 중요한 상황에서는 굳이 RESTful한 API를 구현할 필요는 없다.
3. RESTful 하지 못하는 경우
URI 규칙을 올바르게 지키지 않은 API는 REST API의 설계 규칙을 올바르게 지키지 못한 시스템은 REST API를 사용하였지만 RESTful 하지 못한 시스템이라고 할 수 있다.
Client Side가 정형화 되어있지 않은 환경에서 HTTP의 Response 규약을 지키지 않고 본인들이 만들어넨 JSON 컨벤션으로 응답하는 경우 표준을 지키지 않아 개발 속도를 저하하는 문제를 발생시킨다.
ex1) CRUD 기능을 모두 POST로만 처리하는 API
ex2) route에 resource, id 외의 정보가 들어가는 경우(/students/updateName)
REST API란?
REST API : 클라이언트와 서버 간의 두 컴퓨터 시스템이 인터넷을 통해 정보를 안전하게 교환하기 위해 사용하는 인터페이스를 말한다.
API(애플리케이션 프로그래밍 인터페이스)는 애플리케이션이나 디바이스가 서로 간에 연결하여 통신할 수 있는 방법을 정의하는 규칙 세트이다.
REST API는 REST(REpresentational State Transfer) 아키텍처 스타일의 디자인 원칙을 준수하는 API이다. 이러한 이유로 REST API를 RESTful API라고도 한다.
REST란?
REST는 자원 기반의 구조 (ROA: Resource Oriented Architecture) 설계의 중심에 Resoure가 있고 HTTP Method를 통해 Resource를 처리하도록 설계된 아키텍쳐를 의미한다.
이 때 가장 중요한 규칙은 다음 두가지이다.
여기서 자원은 문서, 사진, 그림, 데이터 등 소프트웨어가 관리하는 모든 것을 의미한다.
이러한 자원들을 HTTP URI(Uniform Resource Identifier)를 통해 명시해야 한다. 때문에 웹의 모든 자원에 고유한 ID인 HTTP URI 를 부여한다.
예를 들어 DB의 영화 정보가 자원일 때, /movies를 자원의 표현으로 정한다. ex)
GET /movies/1그리고 HTTP Method를 통해 해당 자원(URI)에 대한 'CRUD Operation'을 적용한다.
REST의 구성
REST의 특징
1) Uniform (유니폼 인터페이스)
2) Stateless (무상태성)
3) Cacheable (캐시 가능)
4) Self-descriptiveness (자체 표현 구조)
5) Client - Server 구조
6) 계층형 구조
REST의 장단점
장점
단점
REST가 필요한 이유
최근의 서비스(애플리케이션)의 개발 흐름은 멀티 플랫폼, 멀티 디바이스 시대로 넘어와 있다. 단순히 하나의 브라우저만 지원하면 되었던 이전과는 달리, 최근의 서버 프로그램은 여러 웹 브라우저는 물론이며, 아이폰, 안드로이드 애플리케이션과의 통신에 대응할 수 있어야 한다.
따라서 플랫폼에 맞추어 새로운 서버를 만드는 수고를 들이지 않기 위해 범용적으로 사용성을 보장하는 서버 디자인이 필요하게 되었었다.
그래서 다시 REST API란?
REST API : REST 기반으로 서비스 API를 구현한 것
최근 OpenAPI(누구나 사용할 수 있도록 공개된 API: 구글 맵, 공공 데이터 등), 마이크로 서비스(하나의 큰 애플리케이션을 여러 개의 작은 애플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍처) 등을 제공하는 업체 대부분은 REST API를 제공한다.
이 API는 항상 메뉴얼도 힘께 제공해야 한다. URI를 모르면 클라이언트는 사용할 수 없기 때문이다.
RESTful
1. RESTful 하다?
REST 원리를 따르는 시스템은 RESTful이란 용어로 지칭하므로 ‘REST API’를 제공하는 웹 서비스를 ‘RESTful’하다고 할 수 있다.
2. RESTful의 목적
이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것이 목적이다.
RESTful한 API를 구현하는 근본적인 목적이 성능 향상에 있는 것이 아니라 '일관적인 컨벤션을 통한 API의 이해도 및 호환성을 높이는 것'이 주 동기이니, 성능이 중요한 상황에서는 굳이 RESTful한 API를 구현할 필요는 없다.
3. RESTful 하지 못하는 경우
URI 규칙을 올바르게 지키지 않은 API는 REST API의 설계 규칙을 올바르게 지키지 못한 시스템은 REST API를 사용하였지만 RESTful 하지 못한 시스템이라고 할 수 있다.
Client Side가 정형화 되어있지 않은 환경에서 HTTP의 Response 규약을 지키지 않고 본인들이 만들어넨 JSON 컨벤션으로 응답하는 경우 표준을 지키지 않아 개발 속도를 저하하는 문제를 발생시킨다. ex1) CRUD 기능을 모두 POST로만 처리하는 API ex2) route에 resource, id 외의 정보가 들어가는 경우(/students/updateName)
참고 자료