REST란?
Representational State Transfer의 줄임말로, 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍쳐의 한 형식이다.
- REST는 기본적으로 웹의 기존 기술과 HTTP프로토콜을 그대로 활용하기 때문에 웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일.
HTTP URI를 통해 자원을 명시하고, HTTP Method(POST,GET,PUT,DELETE)를 통해 해당 자원에 대한 CRUD Operation을 적용함.
즉, REST는 자원 기반의 구조설계의 중심에 Resource가 있고 HTTP Method를 통해 Resource를 처리하도록 설계된 아키텍쳐를 의미함.
쉽게 말해 '웹에 존재하는 모든 자원(이미지, 동영상, DB자원)에 고유한 URI를 부여해 활용'하는 것으로 자원을 정의하고, 자원에 대한 주소를 지정하는 방법론을 의미함.
REST의 장단점
- 장점
• HTTP프로토콜의 인프라를 그대로 사용하므로 REST API 사용을 위한 별도의 인프라를 구출할 필요 없음.
• HTTP 프로토콜의 표준을 최대한 활용하여 여러 추가적인 장점을 함께 가져갈 수 있게 해줌.
• HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용가능.
• 여러가지 서비스 디자인에서 생길 수 있는 문제를 최소화한다.
• 서버와 클라이언트의 역할을 명확하게 분리.
- 단점
• 표준이 존재하지 않음.
• 사용할 수 있는 메소드가 4가지 밖에 없다.(Method형태가 제한적)
• 브라우저를 통해 테스트할 일이 많은 서비스라면 쉽게 고칠 수 있는 URL보다 Header 값이 더 어렵게 느껴질 수 있음.
REST가 필요한 이유
- 애플리케이션 분리 및 통합
- 다양한 클라이언트의 등장.
- 웹뿐만이 아닌 모바일 디바이스에서도 통신할 수 있어야함.
이러한 멀티 플랫폼에 대한 지원을 위해 서비스 자원에 대한 아키텍처를 세우고 이용하는 방법을 모색한 결과, REST에 관심이 많아짐.
REST 구성요소
- 자원: URI
• 모든 자원에는 고유한 ID가 존재, 이 자원은 Server에 존재한다.
• 자원을 구별하는 ID는 '/movies/:id'와 같은 HTTP URI다.
• Client는 URI를 이용해 자원을 지정, 해당 자원의 상태에 대한 조작을 Server에 요청함.
- 행위: HTTP Method
• HTTP프로토콜의 Method를 사용하며 GET,POST,PUT,DELETE와 같은 메서드를 제공.
- 표현
• Client가 자원의 상태(정보)에 대한 조작을 요청하면 Server는 이에 적절한 응답을 보냄.
• REST에서 하나의 자원은 JSON,XML,TEXT,RSS 등 여러형태의 Representation으로 나타낼 수 있다. 주로 JSON, XML를 통해 데이터를 주고받음.
URI / URL ?
URI(Uniform Resource Identifier)는 어떤 자원을 식별하기 위한 데이터 서식을 정의한 기술 표준. 자원을 식별하기 위한 방식으로는 URN과 URI가 있다.
URN은 자원의 이름으로 식별 urn:namespace:the:id:for:file
, URL은 자원의 위치로 식별 https://velog.io/
✅ 즉 URI 범주 안에 URL이 있으며 URL은 쉽게 말하면 도메인 주소형태.
REST 특징
- Server-Client(서버-클라이언트 구조)
• 자원이 있는 쪽이 Server, 자원을 요청하는 쪽이 Client가 됨.
👉 REST Server: API를 제공하고 비지니스 로직처리 및 저장을 책임짐.
👉 Client: 사용자 인증이나 context 등을 직접 관리하고 책임짐.
• 서로 간 의존성이 줄어듬.
- Stateless(무상태)
• HTTP프로토콜은 Stateless Protocol이므로 REST역시 무상태성을 가짐.
• Client의 context를 Server에 저장하지않음.
👉 즉, 세션과 쿠키와 같은 context정보를 신경쓰지 않아도 되므로 구현이 단순해짐
• Server는 각각의 요청을 완전히 별개의 것으로 인식하고 처리.
👉 각 API서버는 Client의 요청만을 단순처리하며 이전 요청이 다음요청의 처리에 연된되어선 안됨.(이전 요청이 DB를 수정해 DB에 의해 바뀌는 것은 허용.)
👉 서버의 처리방식에 일관성을 부여하고 부담이 줄어들며, 서비스의 자유도가 높아짐.
- 캐시처리가능
• 웹 표준 HTTP프로토콜을 그대로 사용하므로 웹에서 사용하는 기존의 인프라를 그대로 활용 가능.
👉 즉, 캐싱기능을 적용할 수 있다. 캐싱 구현은 HTTP 프로토콜 표준에서 사용하는 Last-Modified 태그나 E-Tag를 이용하면 가능하다.
- E-Tag : 메시지에 담겨있는 엔터티를 위한 엔터티 태그를 제공한다. 이를 활용하여 리소스를 식별할 수 있다.
Last-Modified : 엔터티가 마지막으로 변경된 시각에 대한 정보를 제공한다. (파일인 경우 파일 시스템이 제공해 준 최근 변경 시각, 동적으로 생성된 리소스라면 응답이 만들어진 시간)
캐시란 무엇인가?
웹 캐시는 자주 쓰이는 문서의 사본을 자동으로 보관하는 HTTP장치로, 웹 요청이 캐시에 도착했을 때 캐시된 로컬 사본이 존재한다면 그 문서는 원서버가 아닌 그 캐시로부터 제공됨.
캐시 사용의 장점
- 불필요한 데이터 전송을 줄여서 네트워크 요금으로 인한 비용을 줄임.
- 네트워크 병목을 줄여줌. 페이지를 빨리 불러올 수 있다.
- 원 서버에 대한 요청을 줄여줌. 서버는 부하를 줄일 수 있으며 더 빨리 응답 가능
- 거리로 인한 지연을 줄여줌.
RESTful API
REST의 특징을 지키면서 API를 제공하는 것을 의미함.
API란?
'API(Application Programming Interface)는 응용 프로그램에서 사용할 수 있도록, 운영체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스를 뜻함.'
즉,프로그램들이 서로 상호작용하는 것을 도와주는 매개체역할을 함.
1. 서버와 데이터베이스에 대한 출입구역할을 한다.
API는 모든사람이 데이터베이스에 접속하는 것을 방지하기 위해 서버와 데이터베이스에 대한 출입구 역할을 하며, 허용된 사람들에게만 접근성을 부여함.
2. API는 어플리케이션과 기기가 통신할 수 있도록 함.
모바일 어플이나 프로그램이 데이터를 원활히 주고받을 수 있도록 돕는다.
3. 모든 접속을 표준화함.
기계/운영체제 등과 상관없이 누구나 동일한 액세스를 얻을 수 있다. API는 범용 플러그처럼 작동함.
RESTful API 설계가이드
- URI는 정보의 자원을 표현해야함.
- 자원에 대한 행위는 HTTP Method로 표현해야함.
ex) 유저를 삭제할 때 - Delete /users/1
(o) GET /users/delete/1
(x)
- 슬래시 구분자
/
는 계층관계를 나타낼 때 사용. 마지막 문제엔 포함하지 않는다.
요약
- REST API란 HTTP 통신에서 어떤 자원에 대한 CRUD 요청을 Resource와 Method로 표현해 특정한 형태로 전달하는 아키텍쳐 스타일.
👉 웹 상에서 사용되는 자원들을 HTTP URI로 표현, HTTP Method를 통해 상태를 정의하는 방식.
- RESTful API란 REST의 특징을 지키면서 API를 제공.
👉 HTTP 메소드를 목적에 맞게 적절히 사용하며 API를 제공한다.
Reference
https://brainbackdoor.tistory.com/53
https://meetup.toast.com/posts/92
https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html
http://blog.wishket.com/api%EB%9E%80-%EC%89%BD%EA%B2%8C-%EC%84%A4%EB%AA%85-%EA%B7%B8%EB%A6%B0%ED%81%B4%EB%9D%BC%EC%9D%B4%EC%96%B8%ED%8A%B8/