REST와 RESTful API

1. REST (REpresentational Safe Transfer)?

웹에 존재하는 모든 리소스(이미지, 동영상, DB)에 고유한 URI를 부여해 활용하는 것으로, 리소스를 정의하고 리소스에 대한 주소를 지정하는 방법론을 의미한다.

2. REST의 탄생

REST는 웹의 창시자(HTTP) 중의 한 사람인 Roy Fielding의 2000년 논문에 의해서 소개되었다. 현재의 아키텍쳐가 웹의 본래 설계의 우수성을 많이 사용하지 못하고 있다고 판단하면서 웹의 장점을 최대한 활용할 수 있는 네트워크 기반의 아키텍쳐를 소개하면서 REST가 대두되었다.

REST가 대두되기 시작한 큰 이유는 '애플리케이션 분리 및 통합', '다양한 클라이언트의 등장'이다. 애플리케이션의 복잡도가 증가하면서 애플리케이션을 어떻게 분리하고 통합하느냐가 주요 이슈가 되었고 하나의 백엔드 Back-end에서 다양한 클라이언트, 즉 디바이스 Device에 대응하기 위해 중요성이 높아졌다.

3. REST의 구성

- 자원 (Resource) - URI

- 행위 (Verb) - HTTP Method

- 표현 (Representation of Resource)

ex)

- /users GET : 유저 정보를 가져 옴

- /users/{id} GET : 특정 id의 유저 정보를 가져 옴

- /users PUT : 유저 정보를 수정함

① 자원(Resource): URI

모든 리소스에 고유한 ID가 존재하고, 이 자원은 서버에 존재한다. 리소스를 구별하는 ID는 `/groups/:group_id`와 같은 HTTP URI다. 클라이언트는 URI를 이용해서 자원을 지정하고 해당 자원의 상태(정보)에 대한 조작을 서버에 요청한다.

② 행위(Verb): HTTP Method

HTTP 프로토콜의 Method를 사용한다. HTTP 프로토콜은 GET, POST, PUT, DELETE 와 같은 메서드를 제공한다.

③ 표현(Representation of Resource)

클라이언트가 리소스의 상태(정보)에 대한 조작을 요청하면 서버는 이에 적절한 응답(Representation)을 보낸다. REST에서 하나의 자원은 JSON, XML, TEXT, RSS 등 여러 형태의 응답으로 나타내어 질 수 있다. JSON 혹은 XML를 통해 데이터를 주고 받는 것이 일반적이다.

4. REST의 특징

① Uniform (유니폼 인터페이스)

HTTP 표준에만 따른다면, 안드로이드/IOS 플랫폼이든, 특정 언어나 기술에 종속되지 않고 모든 플랫폼에 사용이 가능하며, URI로 지정한 리소스에 대한 조작이 가능한 아키텍처 스타일을 의미한다.

② Stateless (무상태성)

서버 측에서 수행의 컨텍스트(Context) 정보를 저장하지 않는다. 즉, 이전에 어떤 요청을 했는지 같은 정보를 저장하지 않고 독립적으로 처리된다. 세션과 같은 컨텍스트 정보를 신경 쓸 필요가 없어 구현이 단순해진다. 필요하다면, 클라이언트가 자체적으로 관리하여야 한다.

③ Cacheable (캐시 가능)

HTTP 프로토콜을 사용하기 때문에 기존 웹 인프라를 그대로 사용 가능하다. 웹 브라우저에서 HTTP 캐시를 이용하는 것처럼 동일하게 이용이 가능하다. 같은 URI에 대한 요청이 여러번 있을 때 URI 리소스를 매번 서버로 요청하지 않고 클라이언트의 HTTP 캐시에서 미리 가져온 정보를 반환한다.

④ Self-descriptiveness (자체 표현 구조)

REST API 메시지 그 자체로 쉽게 이해할 수 있어야 한다. 별도의 주석이나 문서가 없어도 특정 REST API가 원하는 바를 쉽게 이해할 수 있어야 한다.

 

⑤ Client-Server Architecture (클라이언트 서버 구조)

REST 서버는 API 제공, 클라이언트는 사용자 인증이나 컨텍스트(세션, 로그인 정보 등)을 직접 관리하는 구조로 각각의 역할이 확실히 구분되기 때문에 클라이언트와 서버에서 개발해야 할 내용이 명확해지고 서로간 의존성이 줄어들게 된다.

⑥ Layered System (계층형 시스템)

클라이언트는 대상 서버에 직접 붙었는지 중간에 존재하는 서버와 통신하는지 알 수 없다. API Server는 순수 비즈니스 로직을 수행하고 그 앞단에 보안, 로드밸런싱, 암호화, 사용자 인증 등을 추가하여 구조상의 유연성을 줄 수 있다. 또한 로드밸런싱, 공유 캐시 등을 통해 확장성과 보안성을 향상시킬 수 있다.

1. RESTful API?

REST는 위 정의들을 구현하는 방식에 제약을 두지 않기 때문에 구체적인 가이드라인이 없다. 하지만 RESTful이라는 개념을 통해 그 가이드라인이 제시된다. 즉, REST API의 설계 의도를 정확하게 지켜주는 API를 RESTful API라고 부른다.

RESTful API를 구현하는 근본적인 목적은 성능 향상에 있는 것이 아니라 일관적인 컨벤션을 통한 API의 이해도 및 호환성을 높이는 것이다.

2. RESTful API Design 가이드

다음 2가지 항목을 중점적으로 설계해야 한다.

첫 번째, URI는 정보의 리소스를 표현해야 한다. (리소스 명은 동사보다 명사를 사용)

두 번째, 리소스에 대한 행위는 HTTP Method(GET, POST, PUT, PATCH, DELETE)로 표현한다.

2.1 URI 설계 시 주의해야할 점

① 슬래시 구분자(/)는 계층 관계를 나타내는데 사용한다.

② URI 마지막 문자로 슬래시(/)를 포함하지 않는다.

③ 하이픈(-)은 URI 가독성을 높이는데 사용

④ 밑줄(_)은 URI에 사용하지 않는다.

⑤ URI 경로에는 소문자가 적합하다.

⑥ 파일확장자는 URI에 포함하지 않는다.

2.2 HTTP Method의 알맞은 역할

GET - 리소스를 조회한다.

POST - 리소스를 생성하거나 저장한다.

PUT - 리소스를 전체 수정한다.

PATCH - 리소스를 일부 수정한다.

DELETE - 리소스를 삭제한다.