REST
Representional State Transfer의 약어.
어떤 자원에 대해 CRUD 연산을 수행하기 위해 URI로 GET, POST 방식을 사용하여 요청을 보내며 요청을 위한 자원은 특정한 형태로 표현
URI -> Resource / GET, POST 방식 -> Method / 특정한 형태 -> Representation of Resource
HTTP를 기반으로 XML 또는 JSON을 이용하여 Server - Client가 데이터를 주고 받는 통신 방식
-> 네트워크 상에서 Client와 Server 사이의 통신 방식 중 하나
-> 웹 기존 기술 + HTTP를 그대로 활용하므로 웹의 장점을 최대한 활용할 수 있는 아키텍쳐 스타일
URI
URL = Uniform Resource Locator -> 인터넷 상 자원의 위치
URI = Uniform Resource Identifier -> 인터넷 상의 자원을 식별하기 위한 문자열의 구성
URI가 URL보다 포괄적 범위
구성요소
자원(Resource) - URI
- 클라이언트는 URI를 통하여 서버에 해당 자원의 상태에 대한 조작을 요청
- 자원은 서버에 존재, 모든 자원에는 고유한 ID 존재
- URI에는 자원의 명칭(주로 명사)이 들어가야 함 but 조작하는 행위에 대한 표현 X
행위(Verb) - Method
- HTTP 프로토콜의 메서드를 사용(GET, POST, PUT, DELETE 등)
표현(Representation of Resource)
- 자원에 대한 행위의 '내용'을 정의
- [Client] 자원의 상태(정보)에 대한 조작을 요청 -> [Server] 적절한 응답을 보냄
- REST에서 하나의 자원은 여러 형태의 Representation으로 나타내어 질 수 있음(주로 JSON XML)
특징
-
Server-Client(서버-클라이언트 구조)
Server - API 제공하는 구조
Client - 사용자 인증이나 컨텍스트(세션, 로그인 정보) 등을 직접 관리하는 구조
각각의 역할이 확실히 구분됨.
-> 자원이 있는 쪽이 Server, 자원을 요청하는 쪽이 Client
-> Server와 Client가 개발해야 할 내용이 명확해지고 서로 간 의존성이 줄어듬
-
Stateless(무상태)
HTTP 프로토콜은 Stateless Protocol -> REST 또한 Stateless
무상태성 -> 작업을 위한 상태정보를 따로 저장하고 관리하지 않는다.
API Server - Session,Cookie 정보를 별도로 저장하고 관리하지 않기 때문에 들어오는 요청만을 단순히 처리하면 됨 ->
+ Server는 각각의 요청을 완전히 별개의 것으로 인식하고 처리함.
-
Cacheable(캐시 기능)
기존 웹 표준(HTTP)를 그대로 사용하기 때문에 웹에서 사용하는 인프라를 그대로 활용할 수 있음.
-> HTTP가 가진 캐싱 기능 적용할 수 있음.
-> HTTP 프로토콜 표준에서 사용하는 Last-Modified 태그나 E-Tag를 이용하면 캐싱 구현 가능 -
Layered System(계층화)
REST 서버는 다중 계층으로 구성될 수 있으며 로드 밸런싱, 암호화 계층을 추가해 구조상의 유연성을 둘 수 있고 Proxy, Gateway같은 네트워크 기반의 중간매체를 사용할 수 있게 함 -
Self-descriptiveness (자기 표현)
요청 메시지만 보고도 이를 쉽게 이해할 수 있는 자체 표현 구조로 되어있음.
-
Uniform Interface(인터페이스 일관성)
HTTP 표준에만 따르면 IOS/Android 플랫폼이든 특정 언어나 기술에 종속되지 않고 모든 플랫폼에서 사용할 수 있으며, URI로 지정한 리소스에 대한 조작이 가능한 아키텍처 스타일을 의미
마치며
원래 REST, REST API, RESTful API에 대한 내용을 모두 정리해 올릴 계획이었으나,
더 공부해야 할 방대한 데이터가 남아있다는 생각에 분할해서 올리는게
맞다고 판단이 되어 REST에 관한 글만 작성하게 되었습니다.
수정할 사항이나 추가해야 할 사항이 있다면 댓글이나 이메일로 연락 남겨주세요.
