REST

Rosevillage·2023년 2월 16일
0

REST가 무엇인지 정리한다.

REST

WWW와 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식

REST는 네트위크 아키텍처 원리의 모음으로, '네트워크 아키텍처 원리'란 자원을 정의하고 자원에 대한 주소를 지정하는 방법 전반을 일컫는다.

간단한 의미로는, 웹상의 자료를 HTTP위에서 SOAP나 쿠키를 통한 세션 트랙킹 같은 별도의 전송 계층 없이 전송하기 위한 아주 간단한 인터페이스를 말한다.

REST 아키텍처 스타일 : 6가지 제약조건

  • Client-server architectural(클라이언트-서버구조)

    사용자 인터페이스 문제를 데이터 저장 문제와 분리하는, 문제 분리 원칙을 적용.

    사용자 인터페이스의 이식성 향상과, 서버 구성요소의 단순화를 통한 확장성 개선으로 구성요소가 독립적으로 발전 가능하도록 한다.

  • Statelessness(무상태)

    수신자(대부분 서버)가 세션 정보를 보유하지 않는 통신 프로토콜.

    관련 세션 데이터는 이전 패킷의 컨텍스트 정보 없이 전송된 모든 정보 패킷을 분리하여 이해할 수 있는 방식으로 클라이언트에 의해 수신기로 전송된다.

    이러한 속성은 대용량 애플리케이션에 이상적이며, 세션 정보 보존으로 인한 서버 로드를 제거하여 성능을 향상시킨다.

  • Cacheability(캐시 처리 가능)

    클라이언트와 중개자는 응답을 캐시할 수 있다. 클라이언트가 추가 요청에 대한 응답으로 오래되었거나 부적절한 데이터를 제공하지 못하도록 응답은 암시적으로나 명시적으로 자신을 캐시 가능 또는 불가능으로 정의해야 한다.

    잘 관리되는 캐싱은 일부 클라이언트-서버 상호작용을 부분적 혹은 전체적으로 완전히 제거하여 확장성과 성능을 더욱 향상시킨다.

    캐시는 클라이언트 시스템의 메모리 또는 브라우저 캐시 저장소에서 수행할 수 있고, CDN(Content Delivery Network)에 저장할 수 있다.

  • Layered system(계층화)

    클라이언트는 일반적으로 자신이 최종서버에 직접 연결외더 있는지 중개자에게 연결되어있는지 알지 못한다.

    프록시 혹은 로드 밸런서가 클라이언트와 서버 사이에 배치되어도 통신에 영향을 미치지 않는다.

    중간서버는 부하분산을 활성화하고 공유 캐시를 제공하여 시스템 확장성을 향상시킬 수 있다. 또한 비즈니스 로직과 보안 로직을 분리하여 보안을 웹 서비스위에 레이어로 추가할 수 있다.

  • Code on demand(optional)

    서버는 실행 가능한 코드(Java 애플릿과 같은 컴파일된 구성 요소 또는 JavaScript와 같은 클라이언트측 스크립트)를 전송하여 클라이언트의 기능을 일시적으로 확장하거나 사용자 정의할 수 있다.

  • Uniform Interface

    아키텍처를 단순화하고 작은 단위로 분리하여 각 부분이 독립적으로 발전할 수 있도록한다.

Uniform interface 제약조건

  • Identification of resources(자원의 식별)

    요청 내에 기술된 개별 자원을 식별할 수 있어야 한다. 웹 기반의 REST 시스템에서의 URI 사용을 예로 들 수 있다. 자원 그 자체는 클라이언트가 받는 문서와는 개념적으로 분리되어 있다. 예를 들어, 서버는 데이터베이스 내부의 자료를 직접 전송하는 대신, 데이터베이스 레코드를 HTML, XML이나 JSON 등의 형식으로 전송한다.

  • Manipulation of resources through representations(메시지를 통한 리소스 조작)

    클라이언트가 어떤 자원을 지칭라는 메시지와 특정 메타데이터만 가지고 있다면 이것으로 서버 상의 해당 지원을 변경, 삭제할 수 있는 충분한 정보를 가지고 있다고 본다.

  • Self-descriptive messages(자기서술적 메시지)

    각 메시지는 자신을 어떻게 처리해야 하는지에 대한 충분한 정보를 포함해야 한다.

    예를 들어 MIME type과 같은 인터넷 미디어 타입을 전달한다면, 그 메시지에는 어떤 파서를 이용해야 하는지에 대한 정보도 포함해야 한다.

    클라이언트는 어떻게 그 내용을 처리해야할 지 알 수 있어야 한다. 메시지를 이해하기 위해 그 내용까지 살펴봐야 한다면, 그 메시지는 자기서술적이 아니다.

    단순히 application/xml 이라는 미디어 타입은, 실제 내용을 다운로드 받지 않으면 그 메시지만 가지고는 무엇을 해야할지에 대해 충분히 알려주지 못한다.(Host:..., Content-type:...)

  • Hypermedia as the engine of application state(HATEOAS)

    만약에 클라이언트가 관련된 리소스에 접근하기 원한다면, 리턴되는 지시자에서 구별될 수 있어야 한다. 충분한 콘텍스트 속에서의 URI를 제공해주는 하이퍼텍스트 링크가 그 예다.(LINK: ...)


참고 사이트

Wikipidia-REST

youtube-naver d2-이응준-그런 REST API로 괜찮은가

0개의 댓글