본문으로 바로가기

REST와 RESTful API

category Back-end 2019. 3. 16. 14:45



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 - 리소스를 삭제한다.


출처 : https://seunghyun90.tistory.com/m/42



댓글을 달아 주세요

대마도사 블로그
블로그 이미지 대마도사 님의 블로그
MENU
VISITOR 오늘8 / 전체15,562