REST: 두 판 사이의 차이
내위키
편집 요약 없음 |
편집 요약 없음 |
||
(같은 사용자의 중간 판 2개는 보이지 않습니다) | |||
1번째 줄: | 1번째 줄: | ||
REpresentational State Transfer. | |||
인터넷을 통한 [[웹 API]]를 위한 표준 가운데 하나. 사실상 [[ | 인터넷을 통한 [[웹 API]]를 위한 표준 가운데 하나. 사실상 웹 [[API]]의 표준으로 받아들이고 있으며, REST를 쉽게 구현하기 위한 클라이언트 및 서버 측의 갖가지 구현체들이 나와 있고, 온갖 웹 프레임워크와 앱들도 REST [[API]]를 지원하기 때문에 편리하게 웹을 통해 정보를 주고받을 수 있다. REST를 잘 지원하는 웹 서버를 'RESTful'하다고 부른다. REST를 통해서 컴퓨터에서 데이터를 처리하는 기본 기능인 Create(생성), Read(읽기), Update(갱신), Delete(삭제), 즉 CRUD 작업을 URI 기반으로 처리할 수 있다. | ||
2000년에 로이 필딩이 UC어바인대학교 박사학위 논문을 통해서 제안한 개념이다. 뭐야? 박사학위 논문에 나온 게 표준? 하고 치부할 수도 있을 텐데 로이 필딩은 월드와이드웹의 뼈대인 HTTP 프로토콜 작성에 참여한 주요 인물 중 하나다. | 2000년에 로이 필딩이 UC어바인대학교 박사학위 논문을 통해서 제안한 개념이다. 뭐야? 박사학위 논문에 나온 게 표준? 하고 치부할 수도 있을 텐데 로이 필딩은 월드와이드웹의 뼈대인 [[HTTP]] 프로토콜 작성에 참여한 주요 인물 중 하나다. | ||
Representational state transfer는 '표현적인 상태 전송'이라는 뜻으로 풀이할 수 있다. | Representational state transfer는 '표현적인 상태 전송'이라는 뜻으로 풀이할 수 있다. | ||
REST의 특징으로는 다음과 같은 것들이 꼽힌다. | |||
* 단일한 인터페이스 (uniform interface) : [[HTTP]] 표준에만 따른다면, 어떤 기술이든 적용할 수 있으며, 모든 플랫폼에서 사용가능하다. 웹 서버에서 사용할 수 있는 프로그래밍 언어라면 무엇이든 REST를 위해 쓸 수 있으며, 실제로 웬만한 언어들은 이를 쉽게 프로그래밍할 수 있는 프레임워크나 패키지가 나와 있다. | |||
* 상태 없음 (stateless) : 상태를 관리하기 위해 세션이나 쿠키를 사용할 필요가 없다. 서버와 클라이언트가 계속 연결되어 있는 게 아니라 보통의 [[HTTP]] 웹 통신처럼 요청을 하고, 응답을 하면 그걸로 연결은 끊긴다. 서버가 상태를 관리할 필요가 없어서 부담을 줄여준다. 다만 인증이 필요한 경우에는 REST와는 별개로 세션이나 쿠키를 사용한다. | |||
* 캐시 가능 (cacheable) : 기존의 웹 표준(HTTP)을 그대로 사용하므로 웹에서 사용하는 기술들을 얼마든지 활용할 수 있다. 특히 캐싱을 통해서 서버의 처리 부담이나 통신 시간을 대폭 단축시킬 수 있다. [[HTTP]] 프로토콜 표준에서 사용하는 Last-Modified 태그나 E-Tag를 이용하면 캐싱을 구현할 수 있다. | |||
* 보면 의미를 알 수 있다 (self-Descriptiveness) : REST [[API]] 자체가 워낙 단순하고 쉬운 구조다 보니 [[API]] 메시지만 보고도 이것이 무슨 일을 하는지 충분히 이해할 수 있다. 물론 API를 설계할 때 그렇게 했다는 것을 전제로 하며, REST 표준도 이를 요구한다. | |||
* 클라이언트-서버 통신 (communuication between client-server) : REST 서버는 [[API]]를 제공하며, 클라이언트는 사용자 인증이나 컨텍스트, 즉 세션이나 로그인 정보와 같은 데이터를 직접 관리하는 구조를 원칙으로 한다. 클라이언트와 서버의 역할이 확실히 구분되므로 클라이언트 측과 서버 측 프로그램이 구현해야 할 내용도 명확하고 상호 의존성도 줄어든다. | |||
* 계층화 시스템 (layered System) : 클라이언트에서 보기에는 REST [[API]] 서버만 호출하는 단순한 구조지만 서버는 여러 계층으로 구성할 수도 있다. 예를 들어 순수하게 비즈니스 로직만 수행하는 API 서버를 사용자 인증이나 암호화 등의 일을 처리하는 계층을 추가할 수 있으므로 구조가 유연해진다. |
2021년 5월 15일 (토) 04:53 기준 최신판
REpresentational State Transfer.
인터넷을 통한 웹 API를 위한 표준 가운데 하나. 사실상 웹 API의 표준으로 받아들이고 있으며, REST를 쉽게 구현하기 위한 클라이언트 및 서버 측의 갖가지 구현체들이 나와 있고, 온갖 웹 프레임워크와 앱들도 REST API를 지원하기 때문에 편리하게 웹을 통해 정보를 주고받을 수 있다. REST를 잘 지원하는 웹 서버를 'RESTful'하다고 부른다. REST를 통해서 컴퓨터에서 데이터를 처리하는 기본 기능인 Create(생성), Read(읽기), Update(갱신), Delete(삭제), 즉 CRUD 작업을 URI 기반으로 처리할 수 있다.
2000년에 로이 필딩이 UC어바인대학교 박사학위 논문을 통해서 제안한 개념이다. 뭐야? 박사학위 논문에 나온 게 표준? 하고 치부할 수도 있을 텐데 로이 필딩은 월드와이드웹의 뼈대인 HTTP 프로토콜 작성에 참여한 주요 인물 중 하나다.
Representational state transfer는 '표현적인 상태 전송'이라는 뜻으로 풀이할 수 있다.
REST의 특징으로는 다음과 같은 것들이 꼽힌다.
- 단일한 인터페이스 (uniform interface) : HTTP 표준에만 따른다면, 어떤 기술이든 적용할 수 있으며, 모든 플랫폼에서 사용가능하다. 웹 서버에서 사용할 수 있는 프로그래밍 언어라면 무엇이든 REST를 위해 쓸 수 있으며, 실제로 웬만한 언어들은 이를 쉽게 프로그래밍할 수 있는 프레임워크나 패키지가 나와 있다.
- 상태 없음 (stateless) : 상태를 관리하기 위해 세션이나 쿠키를 사용할 필요가 없다. 서버와 클라이언트가 계속 연결되어 있는 게 아니라 보통의 HTTP 웹 통신처럼 요청을 하고, 응답을 하면 그걸로 연결은 끊긴다. 서버가 상태를 관리할 필요가 없어서 부담을 줄여준다. 다만 인증이 필요한 경우에는 REST와는 별개로 세션이나 쿠키를 사용한다.
- 캐시 가능 (cacheable) : 기존의 웹 표준(HTTP)을 그대로 사용하므로 웹에서 사용하는 기술들을 얼마든지 활용할 수 있다. 특히 캐싱을 통해서 서버의 처리 부담이나 통신 시간을 대폭 단축시킬 수 있다. HTTP 프로토콜 표준에서 사용하는 Last-Modified 태그나 E-Tag를 이용하면 캐싱을 구현할 수 있다.
- 보면 의미를 알 수 있다 (self-Descriptiveness) : REST API 자체가 워낙 단순하고 쉬운 구조다 보니 API 메시지만 보고도 이것이 무슨 일을 하는지 충분히 이해할 수 있다. 물론 API를 설계할 때 그렇게 했다는 것을 전제로 하며, REST 표준도 이를 요구한다.
- 클라이언트-서버 통신 (communuication between client-server) : REST 서버는 API를 제공하며, 클라이언트는 사용자 인증이나 컨텍스트, 즉 세션이나 로그인 정보와 같은 데이터를 직접 관리하는 구조를 원칙으로 한다. 클라이언트와 서버의 역할이 확실히 구분되므로 클라이언트 측과 서버 측 프로그램이 구현해야 할 내용도 명확하고 상호 의존성도 줄어든다.
- 계층화 시스템 (layered System) : 클라이언트에서 보기에는 REST API 서버만 호출하는 단순한 구조지만 서버는 여러 계층으로 구성할 수도 있다. 예를 들어 순수하게 비즈니스 로직만 수행하는 API 서버를 사용자 인증이나 암호화 등의 일을 처리하는 계층을 추가할 수 있으므로 구조가 유연해진다.