REST
"Representational State Transfer"
- 자원을 이름으로 구분하여 해당 자원의 상태를 주고 받는 모든 것을 의미
- 자원(resource)의 표현(representation)에 의한 상태 전달
- 자원: 소프트웨어가 관리하는 모든 것(문서, 그림 등)
- 자원의 표현: 자원을 표현하기 위한 이름(DB의 학생정보가 자원이면 'students'는 자원의 표현
- 상태 전달: JSON 혹은 XML을 통해 데이터를 주고 받는다
- HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고, HTTP Method(POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것을 의미한다.
- 필요한 이유
- 애플리케이션 분리 및 통합
- 다양한 클라이언트의 등장
- 최근의 서버프로그램은 다양한 브라우저와 안드로이드폰, 아이폰과 같은 모바일 디바이스에서도 통신을 할 수 있어야한다.
- 구성요소
- 자원(Resource): URI
- 행위(Verb): HTTP Method
- 표현(Representation of Resource): JSON, XML, TEXT, RSS
- 특징
- Server-Client: 서로간 의존성이 줄어든다.
- Stateless: Client의 context(세션, 쿠키..)를 Server에 저장하지 않는다.
- Cacheable: 웹 표준 HTTP 프로토콜을 그대로 사용하므로 웹에서 사용하는 기존의 인프라를 그대로 활용 가능
- Layered System
- Code-On-Demand: Server로부터 스크립트를 받아 Client에서 실행한다.(Optional)
- Uniform Interface: URI로 지정한 Resource에 대한 조작을 통일되고 한정적인 인터페이스로 수행한다.
REST API
- REST 기반으로 서비스 API를 구현한 것(API: Application Programming Interface)
- 특징
- 사내 시스템들도 REST 기반으로 시스템을 분산해 확장성과 재사용성을 높여 유지보수 및 운용을 편리하게 할 수 있다.
- REST는 HTTP 표준을 기반으로 구현하므로, HTTP를 지원하는 프로그램 언어로 클라이언트, 서버를 구현할 수 있다.
❗ REST API 설계 규칙에 관해서는 https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html 를 확인하자 ❗
RESTful
- 일반적으로 REST라는 아키텍처를 구현하는 웹 서비스를 나타내기 위해 사용되는 용어
- "REST 원리를 따르는 시스템을 지칭"
- 목적
- 이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것
- 일관적인 컨벤션을 통한 API의 이해도 및 호환성을 높이는 것
- 성능이 중요한 상황에선 굳이 RESTful한 API를 구현할 필욘 없다!
❗ 아마 url, uri와 관련이 깊은 것으로 생각된다.. 다음 내용으론 url과 uri의 차이를 알아봐야겠다 ❗
