REST는 'Representational State Transfer'의 약어로 하나의 URI는 하나의 고유한 리소스(Resource)를 대표하도록 설계된다는 개념입니다. 최근에는 서버에 접근하는 기기의 종류가 다양해 지면서 다양한 기기에서 공통으로 데이터를 처리할 수 있는 규칙을 만들려고 하는데 이러한 시도가 REST방식입니다.
REST방식은 특정한 URI는 반드시 그에 상응하는 데이터 자체라는 것을 의미하는 방식입니다. 예를 들어 '/boards/123'은 게시물 중에서 123번이라는 고유한 의미를 가지도록 설계하고, 이에 대한 처리는 GET,POST 방식과 같이 추가적인 정보를 통해서 결정합니다.
REST API는 외부에서 위와 같은 방식으로 특정 URI를 통해서 사용자가 원하는 정보를 제공하는 방식입니다. 최근에 Open API에서 많이 사용되면서 REST방식으로 제공되는 외부 연결 URI를 REST API라고 하고, REST 방식의 서비스 제공이 가능한 것은 'Restful'하다고 표현합니다.
스프링은 3버전 부터 @ResponseBody 에노테이션을 지원하면서 본격적으로 REST방식의 처리를 지원하고 있었고, 그 이전부터 스프링은 Content Negotiation 등을 이용해서 처리할 수 있었습니다. 스프링 4에 들어와서 @RestController가 본격적으로 소개 되었습니다.
1.1 @RestController의 소개
스프링 4버전부터 지원되는 '@Controller 애노테이션만을 사용해서 처리하였고, 화면 처리를 담당하는 JSP가 아닌 데이터 자체를 서비스하려면 해당 메소드나 리턴 타입에 '@ResponseBody' 애노테이션을 추가하는 형태로 작성하였습니다. 기능으로 보자면 이전 버전에 비해 크게 달라진 점은 없지만, 컨트롤러 자체의 용도를 지정한다는 점에서 변화가 있다고 할 수 있습니다.
@ResponseBody 애노테이션은 메소드나 리턴 타입에 사용할 수 있는 애노테이션입니다. 기존 JSP방식의 처리와 달리 @ResponseBody 애노테이션의 처리는 스프링의 MessageConverter에 의해 영향을 받습니다.
스프링에서는 전달된 데이터의 타입에 따라 MessageConverter가 데이터를 가공해서 브라우저(클라이언트)에 전송합니다.
과거에는 개발잦가 직접 MIME 타입을 지정하고, 해당 데이터를 만들어 내는 방식이었는데 지금은 자동화된 처리 방식이라고 이해하는게 좋습니다.
-----------------------------------------
책 내용
REST는 네트워크 구조 원리의 모음으로, 리소스를 정의하고 자원에 대한 주소를 지정하는 방법에 대한 조건들을 의미한다.
즉, 도메인 지향 데이터를 HTTP위에서 부가적인 전송 레이어 없이 전송하기 위한 간단한 구조를 정의한 것이다.
-클라이언트/서버: 웹의 일관된 인터페이스를 따른다는 전제하에 클라이언트와 서버는 독립적으로 구현되어야 한다.
-균일한 인터페이스 : 자원 식별, 표현을 통한 자원 처리, 자기 서술적 메시지, Hypermedia as the Engine of Application State같은 인터페이스 제약에 따라 서로 일관성 있게 상호 운영되어야 한다.
-계층 시스템: 웹의 일관된 인터페이스를 사용해서 프락시 또는 게이트웨이 같은 네트워크 기반의 중간매체를 사용할 수 있어야 한다.
-캐시 처리 : 웹 서버가 응답 데이터마다 캐시 여부를 선언할 수 있어야 한다.
-무상태 : 웹 서버가 클라이언트의 상태를 관리할 필요가 없어야 한다.
-주문형 코드 : 선택사항으로 스크립트나 플러그인 같은 실행 가능한 프로그램을 클라이언트에 전송하여 클라이언트가 실행할 수 있도록 해야 한다.