REST
개요
- REST(Representational State Transfer)는 웹의 창시자(HTTP) 중의 한 사람인 Roy Fielding의 2000년 논문에 의해서 소개되었습니다.
- REST는 웹 서비스 를 만드는 데 사용할 제약 조건 집합을 정의하는 소프트웨어 아키텍처 스타일
특성
-
클라이언트 서버 구조 (Client-Server 구조)
-
클라이언트-서버 제약의 원칙은 관심사 분리입니다.
-
사용자 인터페이스 문제와 데이터 스토리지 문제를 분리하면 여러 플랫폼에서 사용자 인터페이스의 이식성이 향상됩니다.
-
또한 서버 구성 요소를 단순화하여 확장성을 향상시킵니다.
-
웹에서 가장 중요한 점은 분리를 통해 구성 요소가 독립적으로 발전 할 수 있으므로 여러 조직 도메인의 인터넷 규모 요구 사항을 지원할 수 있다는 것입니다.
-
-
무상태성(Stateless)
-
클라이언트-서버 상호 작용에서 상태는 고유 상태와 외부 상태로 구성됩니다.
-
리소스 상태 라고하는 고유 상태 는 서버에 저장되며 서버의 컨텍스트와 독립적 인 정보로 구성되어 서버의 모든 클라이언트와 공유 할 수 있습니다.
-
애플리케이션 상태 라고하는 외부 상태 는 각 클라이언트에 저장되며 서버의 컨텍스트에 따라 달라 지므로 공유 할 수없는 정보로 구성됩니다.
-
클라이언트는 필요할 때 애플리케이션 상태를 서버에 전달해야합니다.
-
서버가 아닌 클라이언트에 애플리케이션 상태를 저장하는 제약으로 인해 통신이 무상태성을 가지게 됩니다.
-
-
캐시 가능(Cacheable)
-
World Wide Web에서와 같이 클라이언트와 중개자는 응답을 캐시 할 수 있습니다.
-
클라이언트가 추가 요청에 대한 응답으로 부실하거나 부적절한 데이터를 제공하는 것을 방지하기 위해 응답은 암시 적으로 또는 명시 적으로 자신을 캐시 가능 또는 캐시 불가능으로 정의해야합니다.
-
잘 관리 된 캐싱은 일부 클라이언트-서버 상호 작용을 부분적으로 또는 완전히 제거하여 확장성과 성능을 더욱 향상시킵니다.
-
-
계층화시스템(Layered system)
-
클라이언트는 일반적으로 자신이 최종 서버에 직접 연결되어 있는지 아니면 중간에 연결되어 있는지 여부를 알 수 없습니다.
-
프록시 또는 부하 분산 장치는 클라이언트와 서버 사이에 위치하고 통신에 영향을 미치지 않습니다.
-
클라이언트 또는 서버 코드를 업데이트 할 필요가 없을 것입니다.
중간 서버는 로드 밸런서를 활성화하고 공유 캐시를 제공하여 시스템 확장성을 향상시킬 수 있습니다. -
또한 웹 서비스 위에 보안을 계층으로 추가 한 다음 비즈니스 로직을 보안 로직과 명확하게 분리 할 수 있습니다.
-
보안을 별도의 계층으로 추가하면 보안 정책이 적용 됩니다.
-
마지막으로, 서버가 다른 여러 서버를 호출하여 클라이언트에 대한 응답을 생성 할 수 있음을 의미합니다.
-
-
유니폼 인터페이스(Uniform Interface)
-
균일 한 인터페이스 제약은 모든 RESTful 시스템 설계의 기본입니다.
-
아키텍처를 단순화하고 분리하여 각 부분이 독립적으로 발전 할 수 있도록합니다.
-
이 균일 한 인터페이스의 네 가지 제약은 다음과 같습니다.
-
요청의 리소스식별(Resource identification in requests)
개별 리소스는 요청에서 식별됩니다 (예 : RESTful 웹 서비스의 URI 사용) .
리소스 자체는 개념적으로 클라이언트에 반환되는 표현과 분리됩니다.
예를 들어 서버는 데이터베이스에서 HTML , XML 또는 JSON 으로 데이터를 보낼 수 있습니다. 이 중 어느 것도 서버의 내부 표현이 아닙니다. -
표현을 통한 리소스 조작(Resource manipulation through representations)
클라이언트가 연결된 모든 메타 데이터를 포함하여 리소스의 표현을 보유하면 리소스의 상태를 수정하거나 삭제할 수있는 충분한 정보가 있습니다. -
자기설명메시지(Self-descriptive messages)
메시지에는 메시지 처리 방법을 설명하기에 충분한 정보가 포함되어 있습니다.
예를 들어, 호출 할 Parser는 미디어유형 으로 지정할 수 있습니다. -
Hypermedia as the engine of application state(HATEOAS)
처음 URI에 액세스한 REST 클라이언트는 서버 제공 링크를 동적으로 사용하여 필요한 모든 리소스를 검색 할 수 있어야합니다.
액세스가 진행되면 서버 는 현재 사용 가능한 다른 리소스에 대한 하이퍼 링크 가 포함 된 텍스트로 응답합니다.
클라이언트가 애플리케이션의 구조 나 역학에 관한 정보로 하드 코딩 될 필요가 없습니다.
-
-
-
코드 요구(Code on demand)(선택사항)
-
서버는 실행 코드를 전송하여 클라이언트의 기능을 일시적으로 확장하거나 사용자 정의 할 수 있습니다.
-
이는 사전 구현에 필요한 기능의 수를 줄여 클라이언트를 단순화합니다.
-
REST API
- REST 아키텍처 제약조건을 준수하는 웹서비스API 를 RESTful API라고합니다.
참고 링크
