[REST] REST란?

REST의 정의와 사용, 장단점에 관하여

Posted by ChaelinJ on February 14, 2021
REST RESTful

안녕하세요!

평소 관심 있던 REST에 관한 프로젝트를 하고 싶어서 공부를 해보았습니다.

  1. REST란? (RESTful, REST API)
  2. REST의 원리와 RESTful API 기준
  3. REST 구성요소
  4. REST의 장점, 단점

1. REST란? (RESTful, REST API)

REST (Representational State Transfer)

  • REST란 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식
    • 하이퍼미디어 시스템: 문서, 그림, 애니메이션, 영상, 소리 등을 조합시킨 멀티미디어를 베이스로 하여 관련하는 데이터를 서로 결부시켜 컴퓨터와 대화하면서 원하는 데이터를 꺼낼 수 있도록 한 것 대표적: 월드 와이드 웹

      출처: https://www.scienceall.com

  • REST의 두 가지 의미
    • REST는 네트워크 아키텍처 원리의 모음
    • 웹 상의 자료를 별도의 전송 계층 없이 전송하기 위한 아주 간단한 인터페이스

      첫 번째의 넓은 의미와 두 번째의 간단한 의미를 보았을 때, REST 아키텍처 형식을 따르면 아주 커다란 소프트웨어 시스템 설계가 가능하고 또한 간단한 XML과 HTTP 인터페이스를 이용해 설계도 가능합니다.

  • RESTful: REST 원리를 따르는 시스템

  • REST API: REST 아키텍처의 제약 조건을 준수하는 애플리케이션 프로그래밍 인터페이스
    • API(Application Programming Interface): 애플리케이션 소프트웨어를 구축하고 통합하는 정의 및 프로토콜 세트
    • API는 때때로 정보 제공자와 정보 사용자 간의 계약으로 지칭되며 소비자에게 필요한 콘텐츠(요청)와 생산자에게 필요한 콘텐츠(호출)를 구성합니다.

      출처: https://www.redhat.com

2. REST의 원리와 RESTful API 기준

REST는 아키텍처 원칙 세트입니다. 표준이 없기 때문에 다양한 방식으로 REST를 구현할 수 있습니다.

간단하게 위의 그림처럼 Request와 그에 맞는 Response를 수행하는 동작으로 진행하며 JSON이나 XML 형식으로 정보를 주고 받습니다. JSON은 사용 언어와 상관 없을 뿐 아니라 인간과 머신이 모두 읽을 수 있기 때문에 널리 사용됩니다.

RESTful API 기준

  • 클라이언트, 서버 및 리소스
    • 요청이 HTTP를 통해 관리되는 클라이언트-서버 아키텍처
  • Stateless cliend-server communication: 요청 간에 클라이언트 정보가 저장되지 않으며, 각 요청이 분리되어 있고 서로 연결되어 있지 않음
  • 클라이언트-서버 상호 작용을 간소화하는 캐시 가능 데이터
    • WWW에서와 같이 클라이언트는 응답을 캐싱할 수 있어야 한다.
  • 정보가 표준 형식으로 전송되도록 하기 위한 구성 요소 간 통합 인터페이스.
    • 요청된 리소스가 식별 가능하며 클라이언트에 전송된 표현과 분리되어야 합니다.
    • 수신한 표현을 통해 클라이언트가 리소스를 조작할 수 있어야 합니다.(충분한 정보가 표현에 포함되어 있기 때문)
    • 클라이언트에 반환되는 자기 기술적 메시지에 클라이언트는 정보를 어떻게 처리해야 할지 설명하는 정보가 충분히 포함되어야 합니다.
    • 하이퍼미디어: 클라이언트가 리소스에 액세스한 후 하이퍼링크를 사용해 현재 수행 가능한 기타 모든 작업을 찾을 수 있어야 합니다.
  • 요청된 정보를 검색하는 데 관련된 서버(보안, 로드 밸런싱 등을 담당)의 각 유형을 클라이언트가 볼 수 없는 계층 구조로 체계화하는 계층화된 시스템.
    • 클라이언트는 보통 대상 서버에 직접 연결되었는지, 또는 중간 서버를 통해 연결되었는지를 알 수 없다.
  • 코드 온 디맨드(선택사항): 요청을 받으면 서버에서 클라이언트로 실행 가능한 코드를 전송하여 클라이언트 기능을 확장할 수 있는 기능.

이처런 REST API는 따라야 할 기준이 있지만, 특정 요구 사항이 있는 SOAP 등의 규정된 프로토콜보다 사용하기 쉬운 편에 속합니다.(그치만 엄청 기네요..)

3. REST 구성요소

  • 자원(Resource), URI
    모든 자원은 고유한 ID를 가지고, ID는 서버에 존재하며 클라이언트는 각 자원의 상태를 조작하기 위해 요청을 보낸다. HTTP에서 이러한 자원을 구별하는 ID는 HTTP URI이다.
  • 행위(Verb), Method
    클라이언트는 URI를 이용해 자원을 지정하고 자원을 조작하기 위해 Method를 사용한다. HTTP 프로토콜에서는 다음의 Method가 제공된다.
    • GET
    • POST
    • PUT
    • DELETE
  • 표현(Representation)
    클라이언트가 서버로 요청을 보냈을 때, 서버가 응답으로 보내주는 자원의 상태를 Represeontation이라 한다. REST에서 자원은 JSON, XML, TEXT, RSS 등 여러형태의 Representation으로 나타낼 수 있다.

4. REST의 장점, 단점

장점

  • 쉬운 사용
    • HTTP 프로토콜 인프라를 그대로 사용하므로 별도의 인프라를 구축할 필요가 없다.
    • Stateless한 특징 때문에 이전 서버에서 진행된 내용에 대해 클라이언트가 알 필요 없으며, 이전의 히스토리에 대해서도 알 필요 없이 해당 URI와 원하는 메소드 자체만 독립적으로 이해하면 된다.
  • 클라이언트-서버 역할의 명확한 분리
    클라이언트는 REST API를 통해 서버와 정보를 주고받는다. REST의 특징인 Stateless에 따라 서버는 클라이언트의 Context를 유지할 필요가 없다.
  • 특정 데이터 표현을 사용가능
    REST API는 헤더 부분에 URI 처리 메소드를 명시하고 필요한 실제 데이터를 ‘body’에 표현할 수 있도록 분리시켰다. JSON , XML 등 원하는 Representation 언어로 사용 가능하다.

단점

  • HTTP Method의 제한
    REST API는 HTTP Method를 사용해 URI를 표현하는데, 이는 다양한 인프라에서 편리하게 사용할 수 있게 해주지만 한편으론 Method 형태가 제한적이란 문제점이 있기도 하다.
  • 표준의 부재
    관리의 어려움과 공식화된 API 디자인 가이드가 존재하지 않아 다수의 이용으로 정당화 된 약속들로 구성되고 움직이게 됩니다.

    이는 표준을 중요하게 생각하는 이용자에겐 불편한 점이 될 수 있습니다.

출처: https://wallees.wordpress.com/2018/04/19rest-api-%EC%9E%A5%EB%8B%A8%EC%A0%90/

감사합니다.

Text by Chaelin. Photographs by Chaelin, Unsplash.

← Previous Post Next Post →