📋 REST란
먼저 REST란 'Representational State Transfer'의 약자로, 직역하자면 '표현적 상태 전송'입니다.
REST는 웹이 갖추어야 할 이상적인 아키텍처(구조)를 의미하며, 해당 기준을 충족한 API를 'RESTful API'라고 합니다.
REST 아키텍처가 되기 위한 'REST 설계 원칙'에는 다음과 같은 6가지 원칙이 존재합니다.
- 클라이언트-서버 분리(Client-Server)
- 무상태(Stateless)
- 캐시 가능성(Cache)
- 일관된 인터페이스(Uniform Interface)
- 계층화된 시스템(Layered System)
- [선택 사항] 코드 온 디맨드(Code-on-Demand)
아래에서 각 조건들을 자세히 살펴보겠습니다.
📋 REST 설계 원칙
1) 클라이언트-서버 분리(Client-Server)
웹 브라우저가 실행되고 있는 클라이언트와 서비스를 제공하는 서버가 존재할 때, 이 둘을 클라이언트-서버 구조로 구성하여 각자의 관심사를 분리합니다.
관심사를 분리하면 클라이언트는 UI 렌더링이나 사용자 요청에만 집중할 수 있고, 서버는 DB나 서비스에 대한 처리에만 집중할 수 있습니다.
결과적으로 클라이언트와 서버는 서로를 신경 쓸 필요 없이 업무를 완전히 독립적으로 수행하게 됩니다.
2) 무상태(Stateless)
서버는 클라이언트가 보낸 요청에 관련한 어떠한 데이터도 저장하지 않습니다.
이것은 각각의 요청이 모두 독립적으로 처리되며, 이전의 요청에 대한 정보를 활용할 수 없다는 의미입니다.
따라서 클라이언트는 요청을 보낼 때마다 처리에 필요한 모든 정보를 담아서 보내야 합니다.
3) 캐시 가능성(Cache)
데이터를 저장할 수 있는 캐시 기능을 활용하여 클라이언트 및 서버가 리소스를 캐시 할 수 있어야 합니다.
캐시 된 데이터로 재사용이 가능해지면, 중복되는 요청 및 다운로드를 피할 수 있게 되어 네트워크 비용을 절감할 수 있습니다.
서버는 클라이언트가 받은 응답을 재사용할 수 있는지 여부를 응답에 담아 전송합니다.
4) 일관된 인터페이스(Uniform Interface)
서버가 표준 형식으로 정보를 전송하는 것으로, 같은 리소스에 대한 모든 API 요청은 요청을 보낸 주체에 관계없이 항상 동일하게 표시되어야 합니다.
그리고 REST API 메시지만 보고도 이를 쉽게 이해할 수 있어야 합니다.
일관된 인터페이스 조건에는 하위 조건 4가지가 존재합니다.
- 일관된 리소스 식별자를 사용합니다. 웹 기반의 REST에서는 URI를 사용하여 리소스에 접근합니다.
- 요청 메시지는 자기 자신을 설명하는 충분한 데이터를 포함해야 합니다. HTTP 기반의 REST에서는 method와 header와 같이 메타 데이터 속 정보로 표현이 가능합니다.
- 서버는 리소스를 적절하게 사용할 수 있는 방법에 대한 메타데이터를 포함하여 클라이언트에게 응답을 전송합니다. HTTP 기반의 REST에서는 헤더의 content-type을 통해, HTML, XML, JSON, text 등의 데이터의 타입을 명시합니다.
- 애플리케이션은 하이퍼링크를 이용하여 전이되어야 합니다. 서버는 클라이언트의 요청에 대한 데이터뿐만 아니라, 관련된 다른 리소스를 동적으로 검색할 수 있도록 하이퍼링크를 포함하여 응답합니다.
5) 계층화된 시스템(Layered System)
클라이언트와 서버 간의 요청 및 응답이 서로 다른 계층에서 수행됩니다.
따라서 클라이언트와 서버 사이에서는 프록시, 게이트웨이 등과 같은 중간 매개 요소가 존재할 수 있습니다.
계층을 분리하면 의존성을 최소화할 수 있습니다.
또한, 현재 통신하고 있는 대상이 클라이언트인지, 서버 혹은 중개자인지 알 수 없게 설계되어야 합니다.
6) [선택 사항] 코드 온디맨드(Code-on-Demand)
REST API는 보통 정적 리소스를 전송하지만, 경우에 따라 응답에 실행 코드를 포함할 수 있습니다.
따라서 온디맨드 방식으로 실행되는 경우, 클라이언트는 받아서 바로 실행 가능한 applet이나 스크립트 파일을 서버로부터 받을 수 있습니다.
클라이언트는 서버에게 실행 가능한 코드를 받아 클라이언트의 기능을 확장할 수 있습니다.
해당 조건은 선택적인 조건으로 REST 아키텍처가 되기 위해 이 조건을 반드시 만족할 필요는 없습니다.
읽어주셔서 감사합니다:)
📋 REST란
먼저 REST란 'Representational State Transfer'의 약자로, 직역하자면 '표현적 상태 전송'입니다.
REST는 웹이 갖추어야 할 이상적인 아키텍처(구조)를 의미하며, 해당 기준을 충족한 API를 'RESTful API'라고 합니다.
REST 아키텍처가 되기 위한 'REST 설계 원칙'에는 다음과 같은 6가지 원칙이 존재합니다.
- 클라이언트-서버 분리(Client-Server)
- 무상태(Stateless)
- 캐시 가능성(Cache)
- 일관된 인터페이스(Uniform Interface)
- 계층화된 시스템(Layered System)
- [선택 사항] 코드 온 디맨드(Code-on-Demand)
아래에서 각 조건들을 자세히 살펴보겠습니다.
📋 REST 설계 원칙
1) 클라이언트-서버 분리(Client-Server)
웹 브라우저가 실행되고 있는 클라이언트와 서비스를 제공하는 서버가 존재할 때, 이 둘을 클라이언트-서버 구조로 구성하여 각자의 관심사를 분리합니다.
관심사를 분리하면 클라이언트는 UI 렌더링이나 사용자 요청에만 집중할 수 있고, 서버는 DB나 서비스에 대한 처리에만 집중할 수 있습니다.
결과적으로 클라이언트와 서버는 서로를 신경 쓸 필요 없이 업무를 완전히 독립적으로 수행하게 됩니다.
2) 무상태(Stateless)
서버는 클라이언트가 보낸 요청에 관련한 어떠한 데이터도 저장하지 않습니다.
이것은 각각의 요청이 모두 독립적으로 처리되며, 이전의 요청에 대한 정보를 활용할 수 없다는 의미입니다.
따라서 클라이언트는 요청을 보낼 때마다 처리에 필요한 모든 정보를 담아서 보내야 합니다.
3) 캐시 가능성(Cache)
데이터를 저장할 수 있는 캐시 기능을 활용하여 클라이언트 및 서버가 리소스를 캐시 할 수 있어야 합니다.
캐시 된 데이터로 재사용이 가능해지면, 중복되는 요청 및 다운로드를 피할 수 있게 되어 네트워크 비용을 절감할 수 있습니다.
서버는 클라이언트가 받은 응답을 재사용할 수 있는지 여부를 응답에 담아 전송합니다.
4) 일관된 인터페이스(Uniform Interface)
서버가 표준 형식으로 정보를 전송하는 것으로, 같은 리소스에 대한 모든 API 요청은 요청을 보낸 주체에 관계없이 항상 동일하게 표시되어야 합니다.
그리고 REST API 메시지만 보고도 이를 쉽게 이해할 수 있어야 합니다.
일관된 인터페이스 조건에는 하위 조건 4가지가 존재합니다.
- 일관된 리소스 식별자를 사용합니다. 웹 기반의 REST에서는 URI를 사용하여 리소스에 접근합니다.
- 요청 메시지는 자기 자신을 설명하는 충분한 데이터를 포함해야 합니다. HTTP 기반의 REST에서는 method와 header와 같이 메타 데이터 속 정보로 표현이 가능합니다.
- 서버는 리소스를 적절하게 사용할 수 있는 방법에 대한 메타데이터를 포함하여 클라이언트에게 응답을 전송합니다. HTTP 기반의 REST에서는 헤더의 content-type을 통해, HTML, XML, JSON, text 등의 데이터의 타입을 명시합니다.
- 애플리케이션은 하이퍼링크를 이용하여 전이되어야 합니다. 서버는 클라이언트의 요청에 대한 데이터뿐만 아니라, 관련된 다른 리소스를 동적으로 검색할 수 있도록 하이퍼링크를 포함하여 응답합니다.
5) 계층화된 시스템(Layered System)
클라이언트와 서버 간의 요청 및 응답이 서로 다른 계층에서 수행됩니다.
따라서 클라이언트와 서버 사이에서는 프록시, 게이트웨이 등과 같은 중간 매개 요소가 존재할 수 있습니다.
계층을 분리하면 의존성을 최소화할 수 있습니다.
또한, 현재 통신하고 있는 대상이 클라이언트인지, 서버 혹은 중개자인지 알 수 없게 설계되어야 합니다.
6) [선택 사항] 코드 온디맨드(Code-on-Demand)
REST API는 보통 정적 리소스를 전송하지만, 경우에 따라 응답에 실행 코드를 포함할 수 있습니다.
따라서 온디맨드 방식으로 실행되는 경우, 클라이언트는 받아서 바로 실행 가능한 applet이나 스크립트 파일을 서버로부터 받을 수 있습니다.
클라이언트는 서버에게 실행 가능한 코드를 받아 클라이언트의 기능을 확장할 수 있습니다.
해당 조건은 선택적인 조건으로 REST 아키텍처가 되기 위해 이 조건을 반드시 만족할 필요는 없습니다.
읽어주셔서 감사합니다:)