REST
Representational State Transfer의 약자로 효율적, 안정적이며 확장가능한 분산시스템을 가져올 수 있는 소프트웨어 아키텍처를 나타내며 HTTP 프로토콜을 HTTP 답게 쓸수있게하는 방법이다.
관련 작성 포스팅 HTTP란? / HTTP Method
REST 구성요소
리소스 : HTTP URI
리소스에 대한 행위 : HTTP Method
리소스에 대한 행위의 내용 : 클라이언트와 서버가 데이터를 주고 받는 형태로 JSON, XML 등이 있다.
REST의 제약조건
Server - Client
SW를 서버, 클라이언트 구조로 나눠 서버는 자원을 갖고 있고, 클라이언트는 서버의 자원을 요청하는 구조
Stateless
HTTP 프로토콜이 무상태 프로토콜이기에 당연히 따라오는 제약조건
서버는 각각의 요청을 어떤 클라이언트에 의해 요청되는 완전히 별개의 것으로 인식하고 처리한다.
Cacheable
GET 요청을 보낼 때 이전 요청에서 받은 Last-Modifed Tag 또는 E-Tag를 함께 보내면 컨텐츠의 변화가 없으면 캐시된 값을 사용하기 때문에 API 서버에 요청을 발생시키지 않아 대량의 요청을 효율적으로 처리할 수 있다.
Layered System
보안, 로드 밸런싱, 암호화를 위한 계층을 추가할 수 있고 프록시 및 게이트웨이 등의 중간 매체를 사용할 수 있다.
Uniform Interface
HTTP 프로토콜을 따르는 모든 플랫폼에 사용이 가능해 느슨한 결합도를 갖는다.
Self-Descriptiveness
요청 메시지만 보고 쉽게 이해할 수 있는 자체 표현 구조로 되있다.
REST API
REST의 제약조건들을 준수하는 API
REST API 디자인 가이드
REST 구성요소가 API에 잘 녹이려면
URI는 정보의 자원(리소스)를 표현할 것
리소스를 표현할 때는 다음과 같은 네이밍 규칙을 따른다.
- 행위를 포함 X > 행위는 HTTP Method로 표현
- 계층 관리 표현을 위해 "/"를 사용하고 마지막엔 포함 X
- 명사 사용
- 소문자 사용
- 복수형 사용
- 구분자는 "-" 사용
- 파일 확장자는 포함 X
자원에 대한 행위는 HTTP Method로 표현할 것
REST API의 이점
확장성
REST API를 구현하는 시스템은 REST가 클라이언트-서버 상호 작용을 최적화하기 때문에 효율적으로 크기 조정할 수 있다. 무상태는 서버가 과거 클라이언트 요청 정보를 유지할 필요가 없기 때문에 서버 로드를 제거한다. 잘 관리된 캐싱은 일부 클라이언트-서버 상호 작용을 부분적으로 또는 완전히 제거한다. 이러한 모든 기능은 성능을 저하시키는 통신 병목 현상을 일으키지 않으면서 확장성을 지원한다.
유연성
RESTful 웹 서비스는 완전한 클라이언트-서버 분리를 지원한다. 각 부분이 독립적으로 발전할 수 있도록 다양한 서버 구성 요소를 단순화하고 분리한다. 서버 애플리케이션의 플랫폼 또는 기술 변경은 클라이언트 애플리케이션에 영향을 주지 않는다. 애플리케이션 함수를 계층화하는 기능은 유연성을 더욱 향상시킨다. 예를 들어, 개발자는 애플리케이션 로직을 다시 작성하지 않고도 데이터베이스 계층을 변경할 수 있다.
독립성
REST API는 사용되는 기술과 독립적이다. API 설계에 영향을 주지 않고 다양한 프로그래밍 언어로 클라이언트 및 서버 애플리케이션을 모두 작성할 수 있다. 또한 통신에 영향을 주지 않고 양쪽의 기본 기술을 변경할 수 있다.
정리
REST 제약조건을 지켜 설계된 API를 REST API라고 하지만 굳이 나눠서 이해할 필요는 없는 것 같다. REST가 레시피라고하면 REST API는 레시피로 만들어진 요리와 같이 REST를 적용한 결과물은 REST API 밖에 없다. SOAP API 와 REST API 같이 레시피가 다른 것 끼리의 비교를 할때만 그 차이점을 명확히 알면 될 것 같다.
참고
https://aws.amazon.com/ko/what-is/restful-api/
https://meetup.nhncloud.com/posts/92