Post

REST

Posted
By your_full_name 5 min read

REST란

  • Representational State Transfer
    • RESTful API를 호출한다면 서버는 요청한 자원에 대한 상태에 대한 표현을 클라이언트에게 전달한다.
      • 상태에 대한 표현은 일반적으로 HTML, XML, JSON 포맷을 가진다.
  • 효율적, 안정적이며 확장 가능한 분산시스템을 가져올 수 있는 소프트웨어 아키텍처 디자인 제약의 모음
  • 어떠한 시스템이 이 제약을 준수한다면 그 시스템은 RESTful 하다고 말한다.

REST의 6가지 제약

Uniform Interface

클라이언트와 서버 간 인터페이스는 다음 네 가지 규칙을 따른다.

Resource-Based

  • 요청에는 자원을 식별할 수 있는 요소가 포함되어야 한다.
  • 자원과 클라이언트로 전달하는 표현은 별개의 것이다.
    • 예를 들어 서버는 데이터베이스 자체를 전달하지 않고 HTML, XML, JSON과 같이 데이터베이스를 표현하는 데이터를 전달한다.

Manipulation of Resources Through Representations

  • 클라이언트가 가지고 있는 자원에 대한 표현은 이를 이용해 서버의 자원을 수정/삭제할 수 있을 만큼 충분해야 한다.

Self-descriptive Messages

  • 메시지는 메시지를 처리하는 방법에 대한 충분한 정보를 포함해야 한다.

Hypermedia as the Engine of Application State (HATEOAS)

  • 클라이언트는 애플리케이션의 초기 URI만 가지고 있어야 하며, 이를 통해 다른 자원이나 상호 작용에 접근할 수 있어야 한다.
    • 이때 하이퍼미디어를 이용하여 접근한다.

Stateless

  • 서버는 API 사용자에 대한 정보를 따로 저장하고 관리하지 않는다.
  • 따라서 요청은 URI, query-string parameter, body, header를 통해 요청을 다루는데 필요한 정보를 전달해야 한다.

Cacheable

  • 클라이언트는 응답을 캐싱할 수 있다.
    • 따라서 응답은 반드시 캐싱 가능 여부를 설정해야 한다.

Client-Server

  • Uniform interface는 클라이언트를 서버로부터 분리한다.
  • 클라이언트는 서버에서 관리하는 데이터 스토리지 등에 신경 쓰지 않고, 서버는 클라이언트에서 관리하는 유저 인터페이스, 유저 상태 등에 신경 쓰지 않아도 된다.
    • 서버는 클라이언트에서 요청이 올 때까지 그냥 기다린다.

Layered System

  • 요청을 보내는 클라이언트와 응답을 보내는 서버 사이에는 여러 서버가 존재한다.
  • 이 서버들은 보안이나 로드 밸런싱, 캐시 등의 역할을 맡으며 요청과 응답에 영향을 끼치지 않아야 한다.
    • 클라이언트는 중간에 몇 층의 계층이 존재하는지 알지 못한다.

Code on Demand (optional)

  • 서버는 로직을 담은 코드를 전송해 일시적으로 클라이언트의 기능을 확장 또는 바꿀 수 있다.

요약

  • REST는 아키텍처 디자인 제약의 모음으로서, REST의 6가지 제약 사항을 준수한다면 RESTful 하다고 말할 수 있다.
  • REST의 6가지 제약 사항으로는 일관된 인터페이스, 무상태성, 캐시 가능성, 클라이언트와 서버의 분리, 계층 구조, 마지막으로 선택 사항인 Code on Demand가 있다.

참고 자료

TIL
Web
This post is licensed under CC BY 4.0 by the author.