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에 관한 글만 작성하게 되었습니다.
수정할 사항이나 추가해야 할 사항이 있다면 이메일로 연락 남겨주세요.