오늘은 REST, REST API, RESTful에 대해 이해 해 보자!
REST란?
“Representational State Transfer” 의 약자로
자원(resource)을 이름으로 구분하여 해당 자원의 상태(정보)를 주고 받는 모든 것을 의미한다.
"자원을 이름으로 구분하고 상태를 주고 받음."
자원 : 웹 사이트에서의 이미지, 텍스트, DB 등..
이름 : URL에서 표현하고자 하는것(representation),주로 명사
상태를 주고받음 :JSON, XML을 통해 데이터를 주고 받는것이 일반적이다.
REST 구성 요소
-
자원(Resource): URI
모든 자원에 고유한 ID가 존재하고, 이 자원은 Server에 존재한다.
자원을 구별하는 ID는 ‘sample/products/003’과 같은 HTTP URI 다.
Client는 URI를 이용해서 자원을 지정하고 해당 자원의 상태(정보)에 대한 조작을 Server에 요청한다. -
행위(Verb): HTTP Method
HTTP 프로토콜의 Method를 사용한다.
HTTP 프로토콜은 GET, POST, PUT, DELETE 와 같은 메서드를 제공한다. -
표현(Representation of Resource)
Client가 자원의 상태(정보)에 대한 조작을 요청하면 Server는 이에 적절한 응답(Representation)을 보낸다.
REST에서 하나의 자원은 JSON, XML, TEXT, RSS 등 여러 형태의 Representation으로 나타내어 질 수 있다.
JSON 혹은 XML를 통해 데이터를 주고 받는 것이 일반적이다.
REST 장점
1.HTTP 프로토콜의 인프라를 그대로 사용하므로 REST API 사용을 위한 별도의 인프라를 구출할 필요가 없다.
2.HTTP 프로토콜의 표준을 최대한 활용하여 여러 추가적인 장점을 함께 가져갈 수 있게 해준다.
3.HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다.
4.Hypermedia API의 기본을 충실히 지키면서 범용성을 보장한다.
5.REST API 메시지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악할 수 있다.
6.여러가지 서비스 디자인에서 생길 수 있는 문제를 최소화한다.
7.서버와 클라이언트의 역할을 명확하게 분리한다.
REST 단점
1.가이드만 제시하지 표준이 존재하지 않는다.(눈치껏 맞추어 짜자)
2.사용할 수 있는 메소드가 4가지 밖에 없다.(GET, POST, PUT, DELETE)
3.브라우저를 통해 테스트할 일이 많은 서비스라면 쉽게 고칠 수 있는 URL보다 Header 값이 왠지 더 어렵게 느껴진다.
4.구형 브라우저가 아직 제대로 지원해주지 못하는 부분이 존재함.
(PUT, DELETE를 사용하지 못하는 점, pushState를 지원하지 않는 점)
REST가 필요한 이유
1.‘애플리케이션 분리 및 통합’
2.‘다양한 클라이언트의 등장’
3.최근의 서버 프로그램은 다양한 브라우저와 안드로이폰, 아이폰과 같은 모바일 디바이스에서도 통신을 할 수 있어야 한다.
4.이러한 멀티 플랫폼에 대한 지원을 위해 서비스 자원에 대한 아키텍처를 세우고 이용하는 방법을 모색한 결과, REST에 관심을 가지게 되었다.
REST 의 특징
1.Uniform Interface (인터페이스 일관성)
URI로 지정한 자원에 대한 조작을 통일되고 한정적인 인터페이스로 수행한다. HTTP 표준에만 따른다면 모든 플랫폼에 사용이 가능하다.
2.Client-Server(클라이언트-서버 구조)
자원이 있는 Server , 자원을 요청하는 Client의 구조를 가진다.
3.Stateless (무상태)
HTTP는 Stateless 프로토콜 이므로 REST 역시 무상태성을 가진다. 클라이언트의 Context 를 서버에 저장하지 않는다.
4.Cachealble (캐시 처리 가능)
웹 표준 HTTP 프로토콜을 그대로 사용하므로 , 웹에서 사용하는 기존의 인프라를 그대로 활용 가능하다.
5. Layered System (계층화)
API 서버는 순수 비즈니스 로직을 수행하고 그 앞단에 사용자 인증 , 암호화 , 로드밸런싱 등을 하는 계층을 추가하여 구조상의 유연성을 줄 수 있다.
6. Self-Descriptiveness(자체 표현 구조)
동사(Method) + 명사(URI) 로 이루어져있어 어떤 메서드에 무슨 행위를 하는지 알 수 있으며 REST API 자체가 매우 쉬워서 API 메세지 자체만 보고도 API를 이해할 수 있다.
그럼 REST API란?
위의 REST의 특징 6개가 원칙인 API디자인 방법
API(Application Programming Interface)란?
서로 다른 프로그램간에 소통할 수 있게 도와주는 통신 규약으로 웹에서는 '서버와 고객간의 통신 규약’을 뜻함. (=서버에게 요청해서 데이터 가져오는 방법)
RESTful은??
REST한 아키택쳐를 구성하는 서비스를 말함.
REST API의 6가지 원칙을 충실히 따라 이해하기 쉽고, 사용하기 쉬운 REST API를 제공하면 그것이 바로 'RESTful하다'라고 한다.
REST API를 6가지 원칙 지키면서 만들기(결국 이것이 REST의 특징이고, RESTful하다고 하는 것임)
-
Uniform Interface
하나의 URL로는 하나의 데이터를 가져와야함 (하나를 가져오기 위한 두개의 URL을 만들지 말자)
간결하고 예측가능하게 작성 (URL 하나를 알면 둘을 알게)
URL 이름짓기 관습을 잘 따르기.(다음 포스트에서 게시) -
Client-server 역할 구분하기
고객들은 그냥 URL 하나만 알면 서버에 있는 자료를 갖다 쓸 수 있다.
고객에게 서버역할을 맡기거나 고객에게 DB에 있는 자료를 직접 꺼낼수 있도록하게 코드를 짜서는 안됨. -
Stateless
요청들은 각각 독립적으로 처리.
요청1이 성공해야 요청2를 보내주고 그런 식으로 요청간의 의존성이 존재하는 코드를 짜면 안됨.
다르게 말하면 요청 하나만으로 자료를 가져오기 충분하도록 요청에 필요한 모든 정보들을 실어 보내는게 좋다. -
Cacheable
요청을 통해 보내는 자료들은 캐싱이 가능해야 함.
그리고 캐싱가능하다고 표시하거나 캐싱 기간을 설정해주어야 한다고 한다. -
Layered System
요청처리하는곳, DB에 저장하는곳, 이런 여러가지 단계(레이어)를 거쳐서 요청을 처리해도 됨. -
Code on Demand(optional)
서버는 고객에게 실제 실행가능한 코드를 전송해줄 수도 있음.
