REST란?
- REST(Representational State Transfer)의 약자로 자원을 이름으로 구분하여 해당 자원의 상태를 주고받는 모든것을 의미한다.
즉 REST란
1) HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고,
2) HTTP Method(POST, GET, PUP, DELETE, PATCH 등)를 통해
3) 해당 자원(URI)에 대한 CRUD Operation을 적용하는 것을 의미한다.
URI(Uniform Resource Identifier)이란?
통합자원식별자라고 부르고
- Uniform은 리소스를 식별하는 통일된 방식을 말합니다.
- Resource란, URI로 식별이 가능한 모든 종류의 자원(웹 브라우저 파일 및 그 이외의 리소스 포함)을 지칭합니다.
- Identifier는 다른 항목과 구분하기 위해 필요한 정보입니다.
-> 즉, URI는 인터넷상의 리소스 "자원자체"를 식별하는 고유한 문자열 시퀀스이다.
URL(Uniform Resource Locator)이란?
네트워크상에서 통합 자원(리소스)의 “위치”를 나타내기 위한 규약
-> 즉, 자원 식별자와 위치를 동시에 보여준다.
-> 웹 사이트 주소 + 컴퓨터 네트워크 상의 자원
- 특정 웹 페이지의 주소에 접속하기 위해서는 웹 사이트의 주소뿐만 아니라 프로토콜(https, http, sftp, smp 등)을 함께 알아야 접속이 가능한데, 이들을 모두 나타내는 것이 URL이다.
CRUD Operation란?
CRUD는 대부분의 컴퓨터 소프트웨어가 가지는 기본적인 데이터 처리 기능인 Create(생성), Read(읽기), Update(갱신), Delete(삭제)를 묶어서 일컫는 말로
REST에서의 CRUD Operation 동작 예시는 다음과 같다.
- Create : 데이터 생성(POST)
- Read : 데이터 조회(GET)
- Update : 데이터 수정(PUT, PATCH)
- Delete : 데이터 삭제(DELETE)
REST 구성 요소
- 자원(Resource) : HTTP URI
- 모든 자원에 고유한 ID가 존재하고, 이 자원은 Server에 존재한다.
- 자원을 구별하는 ID는 ‘/groups/:group_id’와 같은 HTTP URI 다.
- Client는 URI를 이용해서 자원을 지정하고 해당 자원의 상태(정보)에 대한 조작을 Server에 요청한다.
- 자원에 대한 행위 : HTTP Method
- HTTP 프로토콜의 Method를 사용한다.
- HTTP 프로토콜은 GET, POST, PUT, DELETE 와 같은 메서드를 제공한다.
- 자원에 대한 행위의 내용/표현(Representation) : HTTP Message Pay Load
- Client가 자원의 상태(정보)에 대한 조작을 요청하면 Server는 이에 적절한 응답(Representation)을 보낸다.
- REST에서 하나의 자원은 JSON, XML, TEXT, RSS 등 여러 형태의 Representation으로 나타내어 질 수 있다.
- JSON 혹은 XML를 통해 데이터를 주고 받는 것이 일반적이다.
REST의 특징
- 클라이언트-서버 구조 (Client-Server Architecture)
-
클라이언트와 서버가 분리되어 있으며, 클라이언트는 요청을 보내고 서버는 응답을 제공하는 구조이다.
-
이로 인해 클라이언트와 서버의 역할이 명확히 분리되며, 독립적인 확장이 가능하다.
- 무상태성 (Statelessness)
-
서버는 클라이언트의 상태를 저장하지 않으며, 각 요청은 독립적으로 처리된다.
-
클라이언트가 필요한 모든 정보를 요청에 포함해야 하므로 확장성과 성능이 향상된다.
- 캐시 가능 (Cacheable)
-
REST API 응답은 캐시 가능하도록 설계되어야 하며, 이를 통해 성능을 개선할 수 있다.
-
Cache-Control 등의 HTTP 헤더를 사용하여 캐시 정책을 설정할 수 있다.
- 계층화된 시스템 (Layered System)
-
REST 아키텍처는 여러 계층으로 구성될 수 있으며, 각 계층은 독립적으로 동작한다.
-
예를 들어, 로드 밸런서, 프록시, 게이트웨이 등의 중간 계층이 추가될 수 있다.
- 일관된 인터페이스 (Uniform Interface)
-
REST는 리소스를 조작하는 방식이 일관된 인터페이스를 가져야 합니다.
-
주요 원칙으로는 URI를 통한 리소스 식별, 표현 방식의 자기 설명성, HATEOAS(하이퍼미디어를 통한 애플리케이션 상태 전이) 등이 있다.
- 코드 온 디맨드 (Code on Demand, 선택적)
-
REST는 필요할 경우 클라이언트가 실행할 수 있는 코드를 서버에서 전달할 수도 있다.
-
예를 들어, JavaScript 코드나 스크립트를 응답으로 보내 실행할 수 있다. (하지만 일반적인 REST API에서는 잘 사용되지 않는다.)
이러한 특징을 통해 REST는 확장성과 유지보수성이 뛰어나며, 다양한 시스템에서 널리 사용되는 아키텍처 스타일이 되었습니다.
REST의 장단점
장점
- HTTP 프로토콜의 인프라를 그대로 사용하므로 REST API사용을 위한 별도의 인프라를 구축할 필요가 없다.
- HTTP 프로토콜의 표준을 최대한 활용하여 여러 추가적인 장점을 함께 가져갈 수 있게 해준다.
- HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다.
- Hypermedia API의 기본을 충실히 지키면서 범용성을 보장한다.
- REST API메세지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악할 수 있다.
- 여러가지 서비스 디자인에서 생길 수 있는 문제를 최소화한다.
- 서버와 클라이언트의 역할을 명확하게 분리한다.
단점
- 표준이 자체가 존재하지 않아 정의가 필요하다.
- HTTP Method 형태가 제한적이다.
- 브라우저를 통해 테스트할 일이 많은 서비스라면 쉽게 고칠 수 있는 URL보다 Header정보의 값을 처리해야 하므로 전문성이 요구된다.
- 구형 브라우저에서 호환이 되지 않아 지원해주지 못하는 동작이 많다.(익스플로어)
REST API란?
- REST 의 원리를 따르는 API
API(Application Programming Interface)
- 프로그래밍에서 응용 프로그램에서 사용할 수 있도록, 운영 체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스를 뜻한다.
- 즉, "애플리케이션(스마트폰, 카카오톡 서버 등 서로 다른 프로그램)이 인터페이싱하는(요청과 응답을 주고받는) 체계이다.
REST API 설계 규칙
-
URI는 동사보다는 명사를, 대문자 보다는 소문자를 사용
Bad Example http://eddy.com/Running
Good Example http://eddy.com/run -
마지막에 슬래쉬 (/)를 포함하지 않음
Bad Example http://eddy.com/welcome/
Good Example http://eddy.com/welcome -
언더바 대신 하이픈 사용
Bad Example http://eddy.com/my_velog
Good Example http://eddy.com/my-velog -
파일확장자는 URI에 포함하지 않음
Bad Example http://eddy.com/photo.jpg
Good Example http://eddy.com/photo -
행위를 포한하지 않음
Bad Example http://eddy.com/delete-post/1
Good Example http://eddy.com/post/1
RESTful이란?
RESTFUL이란 REST의 원리를 따르는 시스템을 의미합니다. 하지만 REST를 사용했다 하여 모두가 RESTful 한 것은 아닙니다. REST API의 설계 규칙을 올바르게 지킨 시스템을 RESTful하다 말할 수 있으며
모든 CRUD 기능을 POST로 처리 하는 API 혹은 URI 규칙을 올바르게 지키지 않은 API는 REST API의 설계 규칙을 올바르게 지키지 못한 시스템은 REST API를 사용하였지만 RESTful 하지 못한 시스템이라고 할 수 있습니다.
References
