Today : REST, API, REST-API, RESTful
REST-API ( Representational State Transfer)
<간단요약>
▷ Server와 Client간의 표준 HTTP 방식을 통해서 Platform 독립적으로 통신하여 작업을 처리하도록 하는 API.
▷ 기존의 HTTP 표준 방식을 그대로 사용하기 때문에 별도의 메시지 처리를 위한 부하가 없음.
▷ REST 아키텍처 원칙을 이행하는 방식을 RESTful이라고 함. (REST와 RESTful이 서로 다른 개념이 아님)
Wiki :
REST(Representational State Transfer)는 월드 와이드 웹과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식이다. 이 용어는 로이 필딩(Roy Fielding)의 2000년 박사학위 논문에서 소개되었다. 필딩은 HTTP의 주요 저자 중 한 사람이다. 이 개념은 네트워킹 문화에 널리 퍼졌다.
엄격한 의미로 REST는 네트워크 아키텍처 원리의 모음이다. 여기서 '네트워크 아키텍처 원리'란 자원을 정의하고 자원에 대한 주소를 지정하는 방법 전반을 일컫는다. 간단한 의미로는, 웹 상의 자료를 HTTP위에서 SOAP이나 쿠키를 통한 세션 트랙킹 같은 별도의 전송 계층 없이 전송하기 위한 아주 간단한 인터페이스를 말한다. 이 두 가지의 의미는 겹치는 부분과 충돌되는 부분이 있다. 필딩의 REST 아키텍처 형식을 따르면 HTTP나 WWW이 아닌 아주 커다란 소프트웨어 시스템을 설계하는 것도 가능하다. 또한, 리모트 프로시저 콜 대신에 간단한 XML과 HTTP 인터페이스를 이용해 설계하는 것도 가능하다.
REST란
HTTP URI를 통해 Resource를 명시하고, HTTP Method(Post, Get, Put, Delete)를 통해 해당 Resource에 대한 CRUD Operation을 적용한다. 즉, REST는 ROA(Resource Oriented Architecture) 설계의 중심에 Resource가 있고 HTTP Method를 통해 Resource를 처리하도록 설계된 아키텍쳐를 의미한다.
※ CRUD(Create Read Update Delete)
REST Architecture 원칙
▪ Client/Server
- 클라이언트와 서버 아키텍처 스타일을 사용하여, 서로의 기능을 분리하여 구현
- 다양한 플랫폼에 대한 이식성 향상
▪ Uniform Interface (Platform agnostic)
- HTTP 표준에 따르는 일관된 인터페이스를 사용
- 플랫폼, 기술 등에 대해서는 종속적이지 않고 Loosely coupling 이 되도록 하는 형태
▪ Stateless
- Server나 Client에 서비스를 위한 상태 정보를 유지하지 않음. (Ex. HTTP Session)
- 정보의 흐름에 대한 가시성 제공 및 복잡도를 낮춰서 안정적으로 운영 가능.
- Visibility, Reliability, Scalability 향상
* Visibility : 별도의 상태정보 없이 단일 Request에 대해서만 모니터링,
* Reliability : partial failures에서 복구 작업이 편리
* Scalability : 단일 Request에 대한 처리로 빠르게 서버 자원에 대한 회수가 가능하며, 구현도 간소화 됨.
▪ Cache
- 기존 HTTP 프로토콜 기반에서 사용 가능 했던 Cache 기능을 그대로 사용 가능하여, 응답시간 및 성능에 향상
▪ Layered system
- 서버의 서비스를 계층적으로 구성
- 클라이언트가 REST API 서버를 호출을 하게 되면, 서버에서는 내부적으로 계층화 된 서비스(서비스 구현도 독립적으로)
를 통해서 결과 값을 제공.
▪ Code on demand (Optional)
- Scripts나 플러그인 같은 실행 가능한 프로그램을 클라이언트에 전송하여, 클라이언트가 실행
- 기능을 확장하고 구현을 단순화 가능
- 단, 기존의 가시성을 감소 시킬 수 있음.
위의 REST 아키텍처를 구현한 것을 RESTful 하다고 함. (REST를 따르려는 이들을 RESTafrians이라고도 함)
REST의 구성
▪ Resource : 리소스에 대한 정의. URI를 통해서 개별 자원은 독립적인 URI를 가지게 됨.
▪ Action : 리소스에 대한 처리 방법을 정의. HTTP Methon(Post, Get, Put, Delete)를 사용
▪ Message : 리소스에 대한 처리 방법에 대한 상세를 정의. HTTP Message Pay Load를 통해서 표현.
다양한 컨텐츠 타입을 선언하여 사용 가능. (주로 JSON을 많이 사용)
REST의 장점
▪ Open API 제공의 편리
▪ Multi Platform 지원 및 연동 용이
▪ 데이터 형식이 독립적, 원하는 타입(Json, Xml, rss)로 데이터 전달 가능
▪ 기존에 사용하던 HTTP를 그대로 사용
※ 참조
https://speakerdeck.com/leewin12/rest-api-seolgye
https://ko.wikipedia.org/wiki/REST
등..