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