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