RESTful이란
- RESTful은 일반적으로 REST라는 아키텍처를 구현하는 웹 서비스를 나타내기 위해 사용되는 용어이다.
- ‘REST API’를 제공하는 웹 서비스를 ‘RESTful’하다고 할 수 있다.
- RESTful은 REST를 REST답게 쓰기 위한 방법으로, 누군가가 공식적으로 발표한 것이 아니다. 즉, REST 원리를 따르는 시스템은 RESTful이란 용어로 지칭된다.
RESTful의 목적
이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것
RESTful한 API를 구현하는 근본적인 목적이 성능 향상에 있는 것이 아니라 일관적인 컨벤션을 통한 API의 이해도 및 호환성을 높이는 것이 주 동기이니, 성능이 중요한 상황에서는 굳이 RESTful한 API를 구현할 필요는 없다.
RESTful 하지 못한 경우
Ex1) CRUD 기능을 모두 POST로만 처리하는 API
Ex2) route에 resource, id 외의 정보가 들어가는 경우(/students/updateName)
REST의 개념
- REST(Representational State Transfer)의 약자로 자원을 이름으로 구분하여 해당 자원의 상태를 주고받는 모든 것을 의미
- HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고, HTTP Method(POST, GET, PUT, DELETE)를 통해 해당 자원(URI)에 대한 *CRUD Operation을 적용하는 것을 의미한다.
- REST는 자원 기반의 구조(ROA, Resource Oriented Architecture) 설계의 중심에 Resource가 있고 HTTP Method를 통해 Resource를 처리하도록 설계된 아키텍쳐를 의미한다. 웹 사이트의 이미지, 텍스트, DB 내용 등의 모든 자원에 고유한 ID인 HTTP URI를 부여한다.
*CRUD Operation이란
CRUD는 대부분의 컴퓨터 소프트웨어가 가지는 기본적인 데이터 처리 기능인 Create(생성), Read(읽기), Update(갱신), Delete(삭제)를 묶어서 일컫는 말
- REST에서의 CRUD Operation 동작 예시는 다음과 같다.
Create : 데이터 생성(POST)
Read : 데이터 조회(GET)
Update : 데이터 수정(PUT)
Delete : 데이터 삭제(DELETE)
REST 구성 요소
REST는 다음과 같은 3가지로 구성이 되어있다.
-
Resource
서버는 Unique한 ID를 가지는 Resource를 가지고 있으며, 클라이언트는 이러한 Resource에 요청을 보낸다. 이러한 Resource는 URI에 해당한다. -
행위(Verb)
- HTTP 프로토콜의 Method를 사용한다.
- HTTP 프로토콜은 GET, POST, PUT, DELETE 와 같은 메서드를 제공한다.
-
표현(Representation of Resource)
클라이언트와 서버가 데이터를 주고받는 형태로 json, xml, text, rss 등이 있다. 최근에는 Key, Value를 활용하는 json을 주로 사용한다.
REST 특징
-
Server-Client(서버-클라이언트 구조)
자원이 있는 쪽이 Server, 자원을 요청하는 쪽이 Client가 된다.
REST Server: API를 제공하고 비즈니스 로직 처리 및 저장을 책임진다.
Client: 사용자 인증이나 context(세션, 로그인 정보) 등을 직접 관리하고 책임진다. -
Stateless(무상태)
- HTTP 프로토콜은 Stateless Protocol이므로 REST 역시 무상태성을 갖는다.
- Client의 context를 Server에 저장하지 않는다.
즉, 세션과 쿠키와 같은 context 정보를 신경쓰지 않아도 되므로 구현이 단순해진다. - Server는 각각의 요청을 완전히 별개의 것으로 인식하고 처리한다.
각 API 서버는 Client의 요청만을 단순 처리한다.
즉, 이전 요청이 다음 요청의 처리에 연관되어서는 안된다.
물론 이전 요청이 DB를 수정하여 DB에 의해 바뀌는 것은 허용한다. - Server의 처리 방식에 일관성을 부여하고 부담이 줄어들며, 서비스의 자유도가 높아진다.
-
Cacheable(캐시 처리 가능)
웹 표준 HTTP 프로토콜을 그대로 사용하므로 웹에서 사용하는 기존의 인프라를 그대로 활용할 수 있기 때문에 캐싱 기능을 적용할 수 있다. Last-Modified 태그나 E-Tag를 이용하면 캐싱 구현이 가능하므로 대량의 요청을 효율적으로 처리 가능하다.
캐시 사용을 통해 응답시간이 빨라지고 REST Server 트랜잭션이 발생하지 않기 때문에 전체 응답시간, 성능, 서버의 자원 이용률을 향상시킬 수 있다. -
Layered System(계층화)
Client는 REST API Server만 호출한다.
REST Server는 다중 계층으로 구성될 수 있다.
API Server는 순수 비즈니스 로직을 수행하고 그 앞단에 보안, 로드밸런싱, 암호화, 사용자 인증 등을 추가하여 구조상의 유연성을 줄 수 있다.
또한 로드밸런싱, 공유 캐시 등을 통해 확장성과 보안성을 향상시킬 수 있다.
PROXY, 게이트웨이 같은 네트워크 기반의 중간 매체를 사용할 수 있다.- 로드밸런싱 : 서버가 처리해야 할 업무 혹은 요청(Load)을 여러 대의 서버로 나누어(Balancing) 처리하는 것을 의미
- PROXY('대신'의 의미를 가짐) : 중계를 기능하는 것.
보안상의 문제로 직접 통신 할 수 없을때 중계 해주는 서버를 프록시 서버라 부름. - 게이트웨이 : 한 네트워크(segment)에서 다른 네트워크로 이동하기 위하여 거쳐야 하는 지점.
서로 다른 네트워크(이[다를 이] 기종 네트워크)를 연결해줌.
-
Code-On-Demand(optional)
Server로부터 스크립트를 받아서 Client에서 실행한다.
반드시 충족할 필요는 없다. -
Uniform Interface(인터페이스 일관성)
URI로 지정한 Resource에 대한 조작을 통일되고 한정적인 인터페이스로 수행한다.
HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다.
특정 언어나 기술에 종속되지 않는다.
REST API 설계규칙
- URI는 명사를 사용한다.
- 슬래시로 계층 관계를 표현한다.
- URI의 마지막에는 슬래시를 붙이지 않는다.
- URI는 소문자로만 구성한다.
- 가독성이 떨어지는 경우 하이픈을 사용한다.
- 대문자와 소문자로 URI를 정의하면 기억하기 어려우며 잘못 적을 가능성이 높아진다.
