REST(Representational State Transfer)의 약자로 자원을 이름으로 구분하여 해당 자원의 상태를 주고받는 모든 것을 의미한다.
즉 REST란
1. HTTP URI(Uniform Resource Identifier)를 통해 자원을 명시하고,
2. HTTP Method(GET, POST, PUT, DELETE, ..)를 통해
3. 해당 자원(URI)에 대한 CRUD Operation을 적용하는 것을 의미한다
REST 구성 요소
- 자원(Resource) - HTTP URI
- 자원에 대한 행위 - HTTP Method
- 자원에 대한 행위의 내용 - HTTP Message Payload
REST의 특징
1. 표준화된 인터페이스
HTTP 프로토콜을 기반으로 하기 때문에 GET, POST, PUT, DELETE 등 HTTP 메서드를 활용하여 직관적이고 표준화된 요청 방식을 제공한다.
클라이언트와 서버 간의 통신 방식이 명확하다.
2. 언어 및 플랫폼 독립성
REST API는 JSON, XML과 같은 표준 형식을 사용하므로 다양한 언어와 플랫폼에서 쉽게 구현할 수 있다.
클라이언트와 서버가 서로 다른 기술 스택을 사용해도 통신이 가능하다.
3. 확장성
클라이언트와 서버가 서로 독립적으로 동작하므로, 서버 로직 변경 시 클라이언트를 수정할 필요가 없거나 최소화된다.
새로운 기능 추가나 확장에 유연하다.
4. 캐시 활용 가능
HTTP의 기본 캐싱 메커니즘을 활용할 수 있어, GET 요청 결과를 클라이언트 또는 프록시에서 캐싱하여 성능을 높이고 서버 부하를 줄일 수 있다.
5. 무상태성 (Stateless)
각 요청이 독립적이므로 서버는 클라이언트의 상태를 저장하지 않는다. 이를 통해 서버의 리소스 사용을 줄이고 확장성을 높인다.
6. 유연성과 가독성
URL 설계를 통해 자원을 직관적으로 표현하므로, API의 설계와 사용이 이해하기 쉽다.
7. 전송 계층의 독립성
HTTP 외에도 다른 프로토콜(TCP, WebSocket 등)을 사용할 수 있는 구조로 설계할 수 있다.
RESTful 이란
RESTful이란 REST의 원리를 따르는 시스템을 의미한다. 즉, RESTful API는 자원을 URI로 명확히 표현하고 HTTP 메서드를 사용하여 자원을 조작하는 API이다.
REST 제약 조건
만약 이들 중 하나라도 지켜지지 않는다면 이를 REST API라고 할 수 없다
1. Client-Server
- 클라이언트는 서버의 리소스 URI만 알고 있으면 된다
- 클라이언트는 서버에서 어떤 일을 수행하더라도 내부 작업을 알지 않아도 된다
2. Stateless
- HTTP 프로토콜의 특징 중 하나는 stateless하다는 것이므로 REST 역시 무상태성을 갖는다
- 클라이언트에서 서버로의 각 요청에는 그 요청에 필요한 모든 정보가 포함되어야 한다
3. Cache
- 요청에 대한 응답 내의 데이터에 해당 요청은 캐시가 가능한지 여부를 명시해야 한다(
cache-control 헤더)
4. Uniform Interface
- 모든 API가 일관된 방식으로 동작해야 한다
- 예시:
- 자원을 URI로 표현(/users->사용자 리스트,/users/{id}->특정 사용자)
- HTTP메서드 사용
- 데이터 포맷 통일(주로 json)
5. 계층화된 시스템
- 클라이언트와 서버 사이 여러 계층을 두어 시스템을 모듈화하고 확장성을 높인다
- 예시 : 클라이언트 -> 로드 밸런서 -> 애플리케이션 서버 -> 데이터베이스 서버
(클라이언트는 서버가 직접 응답을 준다고 생각하지만, 실제로는 여러 계층이 작업을 처리)
계층이란
- 로드 밸런서 : 요청을 여러 서버로 분산시키는 역할
- 프록시 : 보안 또는 요청 캐싱을 처리
- 게이트웨이 : 클라이언트 요청을 적절히 다른 서버로 전달
6. Code-On-Demand
- 서버에서 실행할 코드를 클라이언트로 보내 실행하게 할 수 있다
- 예시 : 웹에서 자바스크립트를 서버에서 내려보내고, 브라우저가 이를 실행하는 경우(버튼 클릭 시 동작하는 스크립트), 동적인 HTML생성(사용자 입력에 따라 화면이 바뀌는 경우)
- 보안상 잘 사용하지 않는다
URL, URI, URN
아래 그림에서 볼 수 있듯이, URI는 URL과 URN을 포함하고 있다. 이들의 각 뜻은 다음과 같이 정의할 수 있다
- URI : 자원의 식별자(identifier)
- URL : 위치(location)
- URN : 이름(name)
URI(Uniform Resource Identifier)
URI는 리소스를 식별하기 위한 모든 것이다.
- 웹에서 사용되는 모든 자원의 이름이나 위치를 나타낼 수 있다
- URI는 두 가지 하위 유형으로 나뉜다: URL, URN
- 예시 :
https://example.com,isbn:978-3-16-148410-0
URL(Uniform Resource Locator)
URL은 URI의 한 종류로 리소스의 위치(주소)를 나타낸다
- 리소스가 어디에 있는지와, 그것에 접근하는 방법(프로토콜)을 포함한다
- '위치'를 기준으로 리소스를 식별한다고 이해하면 된다
- 구성요소
- protocol: 리소스에 접근하는 방법(http,https,ftp, ..)
- 호스트/도메인 : 리소스가 있는 서버의 주소(example.com)
- 경로 : 서버 내 리소스의 경로(/page.html)
- 쿼리 문자열 : 추가 데이터 전달(?id=1234)
URN(Uniform Resource Name)
URN은 URI의 또 다른 하위 유형으로, 리소스의 이름을 나타낸다
- 리소스를 고유하게 식별하지만, 위치를 나타내지 않는다
- 위치와 무관하게 리소스를 식별할 수 있다
- 예시 :
urn:isbn:978-3-16-148410-0->책의 isbn번호,urn:uuid:123e4567-e89b-12d3-a456-426614174000-> UUID
정리
- URI는 인터넷 상에서 특정 자원을 가리키는 식별자
- URI의 두 가지 형태로 URL과 URN이 있다
- URL은 특정 시점에서 자원의 구체적인 위치를 나타내는데, 만약 자원의 위치가 변경되면 기존 URL은 더 이상 사용 불가능하다는 단점이 있다
- URN은 이러한 URL의 단점을 보완하기 위해 새롭게 정의된 표준인데, URN은 자원에 대해 영속적이고 고유한 식별자를 뜻한다
출처 : https://velog.io/@hyosss/REST-API-REST-API%EC%9D%98-%EC%A0%9C%EC%95%BD-%EC%A1%B0%EA%B1%B4%EB%93%A4
https://inpa.tistory.com/entry/WEB-%F0%9F%8C%90-URL-URI-%EC%B0%A8%EC%9D%B4
