REST

최창효·2022년 4월 24일
CS
0

REST란

  • Representational State Transfer

HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고,
HTTP Method(POST, GET, PUT, DELETE)를 통해 해당 자원(URI)에 대한 제어를 나타내고 전달하는 방식을 REST라고 합니다.

  • REST는 HTTP를 최대한 활용할 수 있도록 설계된 아키텍처 입니다.

REST는 '어떤 자원을 어떻게 하겠어'를 표현하는 방법입니다.
blog/post/9라는 URI를 GET으로 요청했다면? -> 9번 게시글을 보겠어
blog/post/9라는 URI를 DELETE로 요청했다면? -> 9번 게시글을 삭제하겠어

REST API

  • REST하게 설계된 API입니다.
  • API란 어떤 소프트웨어가 다른 소프트웨어로부터 지정된 형식으로 요청, 명령을 받을 수 있는 인터페이스를 얘기합니다.
  • REST API는 그 결과값을 XML혹은 JSON으로 제공합니다.
    • XML과 JSON은 데이터 형식이기 때문에 language에 종속적이지 않습니다.

RESTful?

  • RESTful하다는 말은 REST원칙을 잘 준수했다는 의미입니다.
  • 하지만 REST는 특정 기술이 아닌 아키텍처 스타일 입니다.
    • REST의 모든 원칙을 지키지 않았다고 해서 API가 동작하지 않는 건 아닙니다.
    • REST를 지키면 API의 의미를 표현하기 쉽고, 사용자 입장에서 그 의미를 파악하기 쉽습니다.
    • 하지만 모든 100%의 규칙을 모두 준수하여 REST API를 구현하는 건 어렵습니다.(어쩌면 비효율 적일 수 있습니다.)

REST 아키텍처의 조건

Client-Server

  • 서버는 API를 제공하는 역할을, 클라이언트는 컨텍스트(세션, 로그인정보)를 직접 관리하는 역할을 함으로써 서버와 클라이언트의 역할이 분리됩니다.
  • HTTP 통신을 사용하면 Client-Server조건은 자연스럽게 만족하게 됩니다.

Stateless

  • 요청은 필요한 모든 정보를 담고 있어야 합니다.
    • State로 정보를 부가설명하는 게 아니라 요청 그 자체로 모든 정보를 설명해야 한다는 의미입니다.
  • HTTP 통신을 사용하면 Client-Server조건은 자연스럽게 만족하게 됩니다.

Cache

  • 캐시기능을 사용할 수 있어야 합니다.
  • HTTP 통신을 사용하면 Client-Server조건은 자연스럽게 만족하게 됩니다.

Uniform Interface

  • Uniform Interface의 제약조건
    • identification of resources
      • resouces가 uri로 식별되어야 한다.
    • manipulation of resources through representations
      • representation전송(HTTP의 GET,POST,PUT,DELETE)을 통해 resource를 제약해야 한다.
    • self-descriptive message
      • 메시지는 스스로를 설명해야 한다.
      • 목적지를 추가하거나, Content-Type을 명시하는 등 해당 메시지 속 정보만으로 모든 내용을 해석할 수 있어야 한다.
    • HATEOAS(Hypermedia As The Engine Of Application State)
      • 애플리케이션의 상태는 Hyperlink를 이용해 전이되어야 한다.
      • HTTP라면 a태그를 통해, JSON이라면 Link태그를 통해 HATEOAS를 만족시킬 수 있다.
      • 데이터가 그 다음 작업으로 어떤 행동을 해야하는지에 대한 정보까지 넘겨주어야 한다는 의미입니다.

Layered System

  • 계층화된 구성이 가능해야 한다.
    • Server를 다중 계층으로 구성하며, API Server는 순수 비즈니스 로직만을 수행합니다. (암호화, 로드밸런싱 등의 추가기능은 다른 계층에서 수행합니다.)
  • HTTP 통신을 사용하면 Client-Server조건은 자연스럽게 만족하게 됩니다.

Code-on-Demand(Optional)

  • 서버에서 코드를 클라이언트에 보내 실행할 수있어야 한다.(Javascript)

오늘날 REST API는?

  • Uniform Interface를 준수하지 못하고 있어 진정한 REST가 아닙니다.

    • 특히 Self-descriptive와 HATEOAS를 만족하지 못하는 경우가 많기 때문입니다.

  • Uniform Interface를 만족해야 하는 이유는 무엇일까요?

    • 서버와 클라이언트가 각각 독릭적으로 진화해야 하기 때문입니다.
      • 독립적인 진화란 서버의 기능이 변경되어도 클라이언트를 업데이트 할 필요가 없으며, 반대의 경우에도 마찬가지여야 한다는 의미입니다.
      • 서버에 새로운 API가 추가되고 API가 변경되고 URI가 바껴도 클라이언트는 업데이트할 필요가 없어야 한다는 뜻입니다.

  • 우리의 API가 반드시 RESTful해야 하는건 아닙니다.

    • 시스템 전체를 통제할 수 있다면 REST하지 않아도 괜찮습니다.
      • 내가 클라이언트와 서버를 모두 관리하는 경우
    • 진화에 관심이 없다면 REST하지 않아도 괜찮습니다.
      • 서버가 변경될때마다 클라이언트를 업데이트 하는 걸 꺼려하지 않는 경우
    • 위의 두 상황이 아니라도 자의적으로 RSET수준을 선택할 수 있습니다.
  • 왜 오늘날의 API가 REST하기 힘들까요?
    • API는 Media Type을 HTML이 아닌 JSON을 사용하기 때문입니다.
    • HTML은 a태그로 Hyperlink도 쉽게 구현할 수 있고 Self-descriptive역시 쉽게 정의 가능합니다.
    • 반면 JSON은 자체적인 Hyperlink의 정의가 없으며 Self-descriptive역시 불완전 합니다. (JSON전반의 명세를 해석하더라도 데이터 속 변수가 어떤 의미인지는 알기 어렵습니다.)

과연

대부분의 REST API가 만족하지 못하고 있는 Self-descriptive와 HATEOAS는 REST API의 최종목표인 독립적 진화에 도움이 될까요?

  • 서버나 클라이언트가 변해도 Self-descriptive하면 메시지 만으로 해석이 가능하기 때문에 독립적 진화에 도움이 됩니다.
  • late binding이 되기 때문에 서버가 링크를 바꿔도 클라이언트는 아무런 수정사항이 없기 때문에 독립적 진화에 도움이 됩니다.

그렇다면

어떻게 JSON을 사용하는 API를 REST하게 만들 수 있을까요?

  • JSON에 Self-descriptive를 설정하는 방법

    1. Media Type방식
      • 미디어 타입을 정의한 뒤 IANA에 해당 미디어 타입을 등록합니다.
      • 공식참조사이트에 내 JSON파일의 id변수는 이런의미로 썼고, title변수는 이런의미로 썼어요 라고 남긴 뒤 해당 참조사이트의 주소를 JSON에 포함시킨다고 이해하면 됩니다.
    2. Profile방식
      • id변수와 title변수의 의미를 정의한 명세를 만들고 해당 링크를 JSON에 Link 값으로 포함시킵니다.

  • JSON에 HATEOAS를 설정하는 방법

    1. Data로 설정한다.
      • data에 하이퍼링크를 달아둡니다.
    2. HTTP헤더를 이용한다.

References

profile
최창효
기록하고 정리하는 걸 좋아하는 백엔드 개발자입니다.
이전 포스트

예외처리

다음 포스트

백준 1080번: 행렬

0개의 댓글

관련 채용 정보