REST(Representational State Transfer)란?
REST란?
REST는 Representational State Transfer의 줄임말로 애플리케이션 개발의 *아키텍처 중 하나입니다.
(*아키텍처 : 애플리케이션을 설계, 제작하는데 사용하는 패턴과 기술의 총칭)
직역하자면 '대표 상태 전송' 정도의 뜻이 되겠습니다. 뭔 소린지 하나도 모르겠으니 그냥 다음으로 넘어갑시다.
* 글을 읽기 전에 : 이 글은 HTTP에 대한 이해를 어느 정도 필요로 하니 이전 게시글을 참조해주세요.
HTTP(Hypertext Transfer Protocol)란?
HTTP란? HTTP는 Hypertext Transfer Protocol의 줄임말로 웹 상에서 브라우저와 서버가 데이터를 주고 받을때 사용하는 *프로토콜입니다. 이름에 Hypertext가 포함되어 있긴 하지만 사실 Hypertext 뿐만 아니
tibetsandfox.tistory.com
자세히 알아보기
REST는 기본적으로 아래의 개념입니다.
1. 웹 애플리케이션 상에 존재하는 모든 리소스에 대해 고유의 URI를 부여하고
- 리소스는 미디어, DB데이터 등을 모두 포함합니다.
2. HTTP Method(GET, POST, PUT, DELETE)를 이용해 리소스에 대해 CRUD 명령을 적용
- CRUD는 CREATE, READ, UPDATE, DELETE의 줄임말입니다.
|
CRUD |
HTTP Method |
|
CREATE |
POST |
|
READ |
GET |
|
UPDATE |
PUT |
|
DELETE |
DELETE |
즉 위에서 말한 '대표 상태 전송'이
URI가 부여된 리소스(URI가 리소스를 대표)의 상태를 응답으로 전송한다는 의미라고 이해할 수 있겠습니다.
여기서 응답(Response)는 JSON이나 XML등의 형식으로 나타납니다.(XML은 잘 안쓰는 것 같습니다.)
그림으로 나타내자면 다음과 같습니다.
REST의 구성 요소
REST는 다음 3가지의 요소로 구성됩니다.
1. 자원(Resource)
- 자원은 서버에 존재하는 데이터의 총칭입니다. 모든 자원은 고유의 URI(URL)을 가지며 클라이언트는 이 URI를 지정하여 해당 자원에 대해 CRUD 명령을 수행할 수 있습니다. (ex: /resource/1)
2. 행위(Verb)
- 행위는 클라이언트가 HTTP Method를 이용하여 자원을 조작하는 것을 의미합니다.
3. 표현(Representation)
- 클라이언트가 HTTP Method로 자원을 조작하면 서버가 그에 대한 응답(JSON, XML)을 보내는데 그것을 의미합니다.
REST의 특징
1. 서버-클라이언트 구조(Server-Client Architecture)
- 서버는 API 제공, 클라이언트는 유저에 대한 처리를 전담하는 구조를 가지기 때문에 서버와 클라이언트의 역할을 분명하게 구분할 수 있습니다.
2. 무상태성(Stateless)
- HTTP를 이용하는 만큼 Stateless의 특성을 가집니다. 각각의 요청에 대한 정보를 저장하지 않고 별개의 요청으로 처리합니다. 덕분에 구현이 쉽고 서버의 부담을 덜어줄 수 있습니다.
3. 캐시 가능(Cacheable)
- HTTP를 사용하기 때문에 웹의 기본 인프라를 사용할 수 있습니다. 따라서 캐시 기능을 이용해 같은 URI에 대한 반복된 요청을 효율적으로 처리할 수 있습니다.
4. 일관된 인터페이스(Uniform Interface)
- HTTP를 사용할 수 있는 환경이라면 플랫폼에 상관없이 사용할 수 있으며 리소스의 타입에 상관 없이 같은 형태의 요청으로 처리됩니다.
5. 자체적인 표현 구조(Self-Descriptiveness)
- JSON, XML 등을 이용하는 메세지 구조로 해당 메세지가 무엇을, 어떤 행위를 의미하는지 직관적으로 이해할 수 있습니다.
6. 계층 구조(Layered System)
- 클라이언트는 대상 서버와 직접 통신하는지 아니면 중간 서버와 통신하는지 알 수 없습니다. 따라서 클라이언트와 서버의 통신 사이에 보안이나 로드 밸런싱등을 위한 중간 계층을 추가할 수 있습니다.
REST의 장단점
장점
1. 별도의 인프라 구축 필요x
- HTTP를 사용하기 때문에 별도의 인프라를 구축할 필요가 없습니다.
2. 클라이언트와 서버의 분리
- 클라이언트와 서버는 REST API를 통해 정보를 주고 받기 때문에 둘 간의 역할이 명확하게 분리됩니다.
3. 플랫폼에 독립적
- HTTP를 사용 가능한 환경이라면 플랫폼에 상관없이 사용 가능합니다.
4. 쉬운 사용
- 메세지가 자체적으로 무엇을 의미하는지 표현하고 있기 때문에 사용이 쉽습니다.
단점
1. 표준이 존재하지 않음
- 명확한 표준이 존재하지 않습니다. 따라서 REST의 특징을 따르지 않으면서 REST API로 설계되는 이상한 API가 탄생할 수 있으며 관리가 어렵습니다.
2. HTTP Method의 한계
- HTTP Method를 사용하기 때문에 CRUD라는 단순한 행위의 Method만 지원합니다.
3. RDBMS와 맞지 않음
- REST에서는 리소스를 JSON, XML등의 형태로 표현하는데 이는 RDBMS와는 맞지 않는 형태입니다. 그래서 NoSQL쪽이 더 선호되는 추세입니다.
REST API
REST의 규칙을 지키면서 만든 API를 REST API 혹은 RESTful API라고 부릅니다.
이에 대해서는 추가적으로 다루도록 하겠습니다.
(여기서 다루면 글이 너무 길어질 것 같네요)
