위의 사이트를 참고하면서 작성한 내용입니다.
#정의
REST: REpresentational State Transfer
웹(HTTP)의 장점을 활용한 아키텍처
월드 와이드 웹과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식
엄격한 의미로 REST는 네트워크 아키텍처 원리의 모음
'네트워크 아키텍처 원리'란 자원을 정의하고 자원에 대한 주소를 지정하는 방법 전반을 일컫음.
REST의 요소
- Method
Idempotent: 한 번 수행과 여러 번 수행의 결과가 같나?- Resource
- REST API의 주요한 정보
- URI
- 모든 것을 Resource(명사)로 표현하고, 세부 Resource에는 id를 붙임
- Message
- 메시지 포맷이 존재 (JSON, XML)
출처: https://gyoogle.dev/blog/web-knowledge/REST%20API.html#REST 아키텍처에 적용되는 6가지 제한 조건
인터페이스 일관성(Uniform Interface)
- HTTP 표준만 맞다면, 어떤 기술도 가능한 Interface 스타일
- REST API 정의를 HTTP + JSON으로 하였다면, 특정 언어나 기술에 종속받지 않고, 모든 플랫폼에 사용이 가능한 Loosely Coupling 구조
- Self-Descriptive Messages
- API 메시지만 보고, API를 이해할 수 있는 구조
(Resource, Method를 이용해 무슨 행위를 하는지 직관적으로 이해가능)- HATEOAS(Hypermedia As The Engine Of Application State)
- Application의 상태(State)는 Hyperlink를 통해 전이되어야 함.
- 서버는 현재 이용 가능한 다른 작업에 대한 하이퍼링크를 포함해서 응답해야 함.
무상태(Stateless)
- 각 요청 간 클라이언트의 context가 서버에 저장되어선 안됨
- Request만 Message로 처리하면 되고, 컨텍스트 정보를 신경쓰지 않아도 되므로, 구현이 단순해짐.
- 따라서 REST API 실행 중 실패가 발생한 경우, Transaction 복구를 위해 기존의 상태를 저장할 필요가 있음.
Resource 지향 아키텍처(ROA: Resource Oriented Architecture)
- Resource 기반의 복수형 명사 형태의 정의를 권장.
캐시 처리 가능(Cacheable/Cache Ability)
- WWW에서와 같이 클라이언트는 응답을 캐싱할 수 있어야 함.
- 잘 관리되는 캐싱은 클라이언트-서버 간 상호작용을 부분적으로 또는 완전하게 제거하여 scalability와 성능을 향상시킴
계층화(Layered System)
- 클라이언트는 보통 대상 서버에 직접 연결되었는지, 또는 중간 서버를 통해 연결되었는지를 알 수 없음.
- 중간 서버는 로드 밸런싱 기능이나 공유 캐시 기능을 제공함으로써 시스템 규모 확장성을 향상시키는 데 유용
Code on demand
- 자바 애플릿이나 자바스크립트의 제공을 통해 서버가 클라이언트가 실행시킬 수 있는 로직을 전송하여 기능을 확장시킬 수 있음
클라이언트/서버 구조(Client-Server Architecture)
- 아키텍처를 단순화시키고 작은 단위로 분리함으로써 클라이언트-서버의 각 파트가 독립적으로 개선될 수 있도록 함.