REST에 대한 얕은 개념
요즘 웹을 RESTful 로 개발하는 곳이 많다. 그렇다면, REST는 뭐고, RESTful은 무엇이며 또 RESTful API는 무엇인지. 그 개념을 얄팍하게 정리해보았다. 정의는 주로 위키피디아, 로이 필딩씨의 논문 등을 참조하였으며, 이에 대한 사수님의 설명과 나의 이해를 섞어 작성하였다. 또한, REST에 대한 유명한 한글 포스팅인 그런 REST API로 괜찮은가도 읽어보면 매우 좋다.
정의
REpresentational State Transfer, 네트워크 아키텍처의 한 형식이다. (네트워크 아키텍처란 자원을 정의하고 자원에 대한 주소를 지정하는 방식 전반).
3 가지 구성요소 REpresentation, State, Transfer 이 있다.
1) Reperesentation
URL(Uniform Resource Location)과 URI(Uniform Resource Identification). 어떤 자원인지 자원의 종류 식별 및 자원에 대한 주소
2) State
GET/POST/PUT/DELETE(CRUD) 등 method 행위. 해당 자원에 할 작업을 method로 명시함.
3) Transfer
HTTP(HyperText Transfer Protocol)를 기반으로 Resource를 method에 따라서 전달하는 것. 정보는 HTTP headers/body에 담아서 전달.
=> 즉, REST는 HTTP라는 프로토콜을 기반으로 한 네트워크 아키텍처의 한 종류로, 자원(=정보)에 대한 행위를 전달하는 방식의 한 종류이다. 이처럼 REST는 HTTP 프로토콜을 이용하므로, REST 서비스를 구현하려면 HTTP를 처리하는 엔진(웹 엔진, 웹 서버)이 필요하다.
- 오해: REST는 프로토콜이 아니다. REST는 아키텍처이고, HTTP가 프로토콜이다.
- REST는 HTTP/1.0, HTTP/1.1과 아파치 HTTP서버 프로젝트 공동설립자인 Roy Fielding이라는 사람이 도입한 개념으로, 사실 HTTP를 더 잘 활용하자는 주의에서 나왔다. HTTP 프로토콜을 정확한 의도에 맞게 활용하도록 유도한 아키텍처의 한 형식이다. 돌려 해석하면 사람들이 HTTP를 원래의 의도대로 사용하지 않았다는 것이다.
조건
6가지 조건이 REST아키텍처에 사용된다.
1) Client/Server 구조
- 요청을 하는 자, 응답을 하는 자가 분리되어 있다.
2) Stateless
- Client와 Server는 서로의 상태를 알 필요가 없다. 즉, SSH, TCP와 같이 Connection을 유지하는 상태가 아니라 일방적으로 요청을 보내고 응답을 한다. Stateless를 지원하는 대표적인 프로토콜이 HTTP. REST는 HTTP기반이다.
3) Cacheable
- 클라이언트는 응답을 캐싱할 수 있다. 클라이언트가 서버로부터 받은 응답에 대하여 일시적으로 저장해 두고 동일한 요청의 경우 캐시로부터 받아서 서버의 효율을 높인다
4) Layered System
- 클라이언트는 요청한 서버가 end server인지 중간서버인지 알 수 없고 알 필요도 없다. 네트워크는 계층화되어 있을 수 있고 요청한 서버가 load balancer일 수도 있다. 요청 단계는 여러개 일 수 있으나 클라이언트는 응답을 받기만 하면 된다.
5) Code on demand(Optional)
- 실행 가능한 코드를 전송해서 클라이언트의 기능을 높일 수 있다. 이를테면 JavaScript 코드나 컴파일된 Java Applets을 전송할 수 있다. 또는, Request를 보낼 때에 /{}/ {}에 실행 가능한 object를 보낼 수도 있다.
6) Uniform Interface
REST서비스 디자인에 핵심 조건이다. 4가지로 이루어져 있다
-
Resource Identification in requests.
리소스들은 요청 자체에서 식별 가능하다. 즉, URL+URI Representation으로 리소스를 식별한다.
-
Resource Manipulation through Representations
자원을 조작할 수 있다. 즉, GET/POST/DELETE/PUT 을 사용해서 resource를 변형할 수 있다.
- Self-Descriptive messages
메시지 응답 상태 코드(200 OK, 404 Not Found 등)를 포함해서 돌려준다.
- Hypermedia As The Engine Of Application State(HATEOAS)
Server는 Client가 요청을 보냈을 때에, 해당 요청에 뒤따를 수 있는 요청 정보도 함께 보내준다.
API 요청을 했을 때에, 뒤이어 작업할 수 있는 요청에 대한 정보도 같이 보내준다.
RESTful
위와 같은 REST의 6가지 조건을 (일부) 만족한 서비스를 RESTful 서비스라고 한다. 특히, RESTful API는 REST스럽게 구현한 API로 REST의 특징을 잘 살린 서비스 중 하나이다. 타 시스템끼리의 호환을 용이하게 하며 기존 SOAP(Simple Object Access Protocol), EAI(Enterprise Applcation Integration)를 대체한다.
SOAP(Simple Object Access Protocol): XML기반으로 메시지(요청, 응답)를 네트워크 상에서 교환하는 Web Service용 프로토콜. REST보다 구현이 복잡하다.
구현/구축 방법
REST는 HTTP를 이용한 아키텍처의 한 종류이다. 즉, REST도 HTTP를 처리할 수 있는 웹 엔진 이 필요하다. 웹 서비스를 구축하는 데에 다향한 방법이 있듯이, RESTful 서비스를 만드는 방법/언어도 다양하다.
Spring에서 REST를 구현하는 방법은 기존 웹 구축과 비슷하다.
@Controller, @RequestMapping, @PathVariable, @ResponseBody 와 데이터를 받고 줄 때에 data를 처리해주는 HTTPMessageConverter가 필요하다
1. HTTP reponse return
@ResponseBody 어노테이션을 설정하여 return 값을 기존의 웹에서 View(ex_ xxx.jsp)가 아닌 HTTP Responsebody를 돌려준다. return할 때에 HTTP Response Body에 HttpMessageConveter로 변환된 JSON/XML 등을 반환한다.
2. 데이터 변환
RESTful 서비스에서는 주로 JSON/XML로 데이터를 주고 받는다. JSON/XML형태의 데이터를 자바 object 로 상호 변경 하는 법은 크게 3가지가 있다. 1) String 형태로 받아서 JSON object로 직접 파싱
2) @RequestMapping의 parameter로 consume, produce 명시
@RequestMapping(value="", produces = {"application/json"}, consumes = {"application/json"}, method = RequestMethod.POST)
3) Message Converter class 사용
@RequestBody(json -> 자바오브젝트), @ResponseBody(자바오브젝트 -> json) 에 외부 class 사용
- JacksonHTTP2(HTTP1은 json array지원을 하지 않는다)
- Jaxb(XML <-> 자바오브젝트) 사용
보통 1), 3)의 방법 주로 사용하는데 데이터의 크기가 클 때에는(3레벨 이상의 json array등) 1)번 방법이 속도가 더 빠르다.