"레스트풀"의 두 판 사이의 차이
(→개요) |
(→특징) |
||
13번째 줄: | 13번째 줄: | ||
* Uniform Interface(인터페이스 일관성) : Uniform Interface는 URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일이다. HTTP 표준 [[프로토콜]]에 따르는 모든 [[플랫폼]]에서 사용이 가능하다. 특정 언어나 기술에 종속되지 않는다. | * Uniform Interface(인터페이스 일관성) : Uniform Interface는 URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일이다. HTTP 표준 [[프로토콜]]에 따르는 모든 [[플랫폼]]에서 사용이 가능하다. 특정 언어나 기술에 종속되지 않는다. | ||
* Stateless (무상태성) : 상태가 있다 없다는 의미는 사용자나 [[클라이언트]]의 컨택스트를 서버쪽에 유지 하지 않는다는 의미한다. 세션이나 쿠키등을 별도로 관리하지 않기 때문에 API서버는 요청만을 들어오는 메시지로만 처리하기 때문에 구현이 단순하다. | * Stateless (무상태성) : 상태가 있다 없다는 의미는 사용자나 [[클라이언트]]의 컨택스트를 서버쪽에 유지 하지 않는다는 의미한다. 세션이나 쿠키등을 별도로 관리하지 않기 때문에 API서버는 요청만을 들어오는 메시지로만 처리하기 때문에 구현이 단순하다. | ||
− | * Cacheable (캐시 처리 가능) : REST의 가장 큰 특징 중 하나는 HTTP라는 기존 웹표준을 그대로 사용한다. HTTP가 가진 캐싱 기능이 적용 가능하다. HTTP 프로토콜 표준에서 사용하는 Last-Modified태그나 E-Tag를 이용하면 캐싱 구현이 가능하다. 대량의 요청을 효율적으로 처리하기 위해 캐시가 요구된다. 캐시 사용을 통해 응답시간이 빨라지고 REST Server가 | + | * Cacheable (캐시 처리 가능) : REST의 가장 큰 특징 중 하나는 HTTP라는 기존 웹표준을 그대로 사용한다. HTTP가 가진 캐싱 기능이 적용 가능하다. HTTP 프로토콜 표준에서 사용하는 Last-Modified태그나 E-Tag를 이용하면 캐싱 구현이 가능하다. 대량의 요청을 효율적으로 처리하기 위해 캐시가 요구된다. 캐시 사용을 통해 응답시간이 빨라지고 REST Server가 [[트랙잭션]]이 발생하지 않기 때문에 전체 응답시간, 성능, 서버의 자원 이용률을 향상시킬 수 있다. |
* Self-descriptiveness (자체 표현 구조) : REST의 또 다른 큰 특징 중 하나는 REST API 메시지만 보고도 이를 쉽게 이해 할 수 있는 자체 표현 구조로 되어 있다는 것이다. | * Self-descriptiveness (자체 표현 구조) : REST의 또 다른 큰 특징 중 하나는 REST API 메시지만 보고도 이를 쉽게 이해 할 수 있는 자체 표현 구조로 되어 있다는 것이다. | ||
* Client - Server Architecture (클라이언트 - 서버 구조) : REST 서버는 API를 제공하고, 제공된 API를 이용해서 비즈니스 로직 처리 및 저장을 책임진다. 클라이언트의 경우 사용자 인증이나 컨택스트(세션,로그인 정보)등을 직접 관리하고 책임진다. 서로간의 의존성이 줄어들게 된다. | * Client - Server Architecture (클라이언트 - 서버 구조) : REST 서버는 API를 제공하고, 제공된 API를 이용해서 비즈니스 로직 처리 및 저장을 책임진다. 클라이언트의 경우 사용자 인증이나 컨택스트(세션,로그인 정보)등을 직접 관리하고 책임진다. 서로간의 의존성이 줄어들게 된다. | ||
− | * Layered System (계층화 구조) : | + | * Layered System (계층화 구조) : 클라이언트 입장에서는 REST ApI 서버만 호출한다. REST 서버는 다중 계층으로 구성될 수 있다. 예를 들어 보안, 로드 밸런싱, 암호화, 사용자 인증등등 추가하여 구조상의 유연성을 줄 수 있다. 또한 로드밸런싱, 공유 캐시등을 통해 확장성과 보안성을 향상시킬 수 있다. PROXY, 게이트웨이 같은 [[네트워크]] 기반의 중간 매체를 사용할 수 있다. |
== 구성 == | == 구성 == |
2019년 7월 24일 (수) 15:11 판
레스트풀(RESTful) 또는 간략히 레스트(REST; Representational State Transfer)는 HTTP를 활용하여 리소스 중심으로 데이터를 연계하는 것을 말한다. 기존의 SOAP 방식과 달리 REST는 URL을 직접 호출함으로써 필요한 결과값을 XML 형식으로 가져올 수 있다.
목차
개요
REST는 Representational State Transfer라는 용어의 약자로서 웹의 장점을 최대한 활용할 수 있는 아키텍처이다. 최근의 서버 프로그램은 다양한 브라우저와 안드로이드폰, 아이폰과 같은 모바일 디바이스에서도 통신을 할 수 있어야 한다. 또한 REST 아키텍처는 Hypermedia API의 기본을 충실히 지키면서 범용성을 보장한다.
등장배경
역사
특징
- Uniform Interface(인터페이스 일관성) : Uniform Interface는 URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일이다. HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다. 특정 언어나 기술에 종속되지 않는다.
- Stateless (무상태성) : 상태가 있다 없다는 의미는 사용자나 클라이언트의 컨택스트를 서버쪽에 유지 하지 않는다는 의미한다. 세션이나 쿠키등을 별도로 관리하지 않기 때문에 API서버는 요청만을 들어오는 메시지로만 처리하기 때문에 구현이 단순하다.
- Cacheable (캐시 처리 가능) : REST의 가장 큰 특징 중 하나는 HTTP라는 기존 웹표준을 그대로 사용한다. HTTP가 가진 캐싱 기능이 적용 가능하다. HTTP 프로토콜 표준에서 사용하는 Last-Modified태그나 E-Tag를 이용하면 캐싱 구현이 가능하다. 대량의 요청을 효율적으로 처리하기 위해 캐시가 요구된다. 캐시 사용을 통해 응답시간이 빨라지고 REST Server가 트랙잭션이 발생하지 않기 때문에 전체 응답시간, 성능, 서버의 자원 이용률을 향상시킬 수 있다.
- Self-descriptiveness (자체 표현 구조) : REST의 또 다른 큰 특징 중 하나는 REST API 메시지만 보고도 이를 쉽게 이해 할 수 있는 자체 표현 구조로 되어 있다는 것이다.
- Client - Server Architecture (클라이언트 - 서버 구조) : REST 서버는 API를 제공하고, 제공된 API를 이용해서 비즈니스 로직 처리 및 저장을 책임진다. 클라이언트의 경우 사용자 인증이나 컨택스트(세션,로그인 정보)등을 직접 관리하고 책임진다. 서로간의 의존성이 줄어들게 된다.
- Layered System (계층화 구조) : 클라이언트 입장에서는 REST ApI 서버만 호출한다. REST 서버는 다중 계층으로 구성될 수 있다. 예를 들어 보안, 로드 밸런싱, 암호화, 사용자 인증등등 추가하여 구조상의 유연성을 줄 수 있다. 또한 로드밸런싱, 공유 캐시등을 통해 확장성과 보안성을 향상시킬 수 있다. PROXY, 게이트웨이 같은 네트워크 기반의 중간 매체를 사용할 수 있다.
구성
자원(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 등 여러 형태의 Representation으로 나타내어 질 수 있다.
- JSON 혹은 XML를 통해 데이터를 주고 받는 것이 일반적이다.
장점
- HTTP 프로토콜의 인프라를 그대로 사용하므로 REST API 사용을 위한 별도의 인프라를 구출할 필요가 없다.
- HTTP 프로토콜의 표준을 최대한 활용하여 여러 추가적인 장점을 함께 가져갈 수 있게 해준다.
- HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다.
- Hypermedia API의 기본을 충실히 지키면서 범용성을 보장한다.
- REST API 메시지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악할 수 있다.
- 여러가지 서비스 디자인에서 생길 수 있는 문제를 최소화한다.
- 서버와 클라이언트의 역할을 명확하게 분리한다.
단점
- 표준이 존재하지 않는다.
- 사용할 수 있는 메소드가 4가지 밖에 없다. : HTTP Method 형태가 제한적이다.
- 브라우저를 통해 테스트할 일이 많은 서비스라면 쉽게 고칠 수 있는 URL보다 Header 값이 왠지 더 어렵게 느껴진다.
- 구형 브라우저가 아직 제대로 지원해주지 못하는 부분이 존재한다. : PUT, DELETE를 사용하지 못하는 점과 pushState를 지원하지 않는 점이다.
각주
참고자료
- Nesoy , 〈RESTful이란?〉 , 《블로그》 , 2017-02-06
- 〈REST, REST API, RESTful에 대해 이해한다.〉 , 《넷워크》
같이 보기