REST , RESTful API가 무엇일까?

REST는 Representational State Transfer라는 용어의 약자이다. 직독하면 표현적인 상태 전송이다. TTP/1.0, 1.1 스펙 작성에 참여했었고 아파치 HTTP 서버 프로젝트의 공동설립자이기도한 로이 필딩의 박사학위 논문에서 소개된 아키텍쳐이다.(주의. 표준은 아니고 가이드라인이다.) 

 

REST의 조건

• client-server
  • 서버는 API를 제공, 클라이언트는 인증 등 상태를 가지는 것들을 직접 관리한다.
  • 서버는 자원제공, 클라이언트는 자원 요청을 하는식의 역할이 확실하게 구분되어 상호의존성이 줄어들게 된다.
• stateless
  • 클라이언트와 서버의 통신에는 상태가 없어야 한다.
    • 서버는 클라이언트의 상태를 모르고 모든 요청이 필요한 정보를 전부 가지고 있어야 한다.
    • 로그인등의 기능을 사용하려면 JWT와 같은것을 사용해 클라이언트가 관리해야한다.
  • API서버는 단순히 들어오는 요청만 처리를 하게 되므로 더욱 간단해진다.
• cache
  • 요청에 대한 캐시가 가능하며,  캐시가능여부를 명시해야 한다.
• uniform interface
  • 클라이언트와 서버사이의 인터베이스는 균일(uniform)해야 한다.
    • HTTP표준만 따르면 어느 플랫폼에서 사용이 가능하다.
• layered system
  • 계층으로 구성이 가능해야 하며, 각 레이어에 속한 구성요소는 인접하지 않은 레이어의 구성요소를 볼 수 없어야 한다.
    • 클라이언트는 중간과정에 대해 몰라도 된다는 뜻이다.
• code-on-demand(Optional)
  • 리소스를 어떻게 처리해야하는지에 대한 Code를 제공해야 한다.

주의해야할 부분은 Uniform Interface

나머지 부분도 물론 중요하지만, 좋은 REST 설계를 위해서는 Uniform Interface의 제약조건을 알고 있어야 한다.

• identification of resources
  • URI로 정보의 자원을 표현해야 한다.
• manipulation of resources thorough representations
  • representations를 통해 리소스를 조작해야 한다.
  • GET, POST, PUT, PATCH, DELETE 등을 쓰라고 일단 알아두면 될것같다.
• self-descriptive message
  • 요청이나 응답 메시지는 스스로 설명할 수 있는 정보가 포함되어야 한다.
    • ex) content-type
• HATEOS( hypermedia as the engine of application state)
  • 어플리케이션 상태는 하이퍼링크를 이용해 전이가 되어야 한다.
    • 응답은 다음에 할 수 있는 행위에 대한 링크를 제공한다.
      • ex) 사람이 네이버 홈페이지 링크를 누르면서 돌아다니듯

REST는 왜 쓰는걸까?

기존에는 클라이언트마다 인터페이스를 구현하는 방식이었지만, 최근은 웹, 모바일디바이스, PC 등에서도 같은 기능을 제공하는 경우(멀티플랫폼)가 많아졌기 때문에 균일한 인터페이스가 필요하게 되었다. 그러다 보니 새로운 프로토콜을 만들 필요가 없고(HTTP) 균일한 인터페이스(Uniform interface)를 충족하는 REST에 관심을 가지게 되었다.

REST의 장단점

장점

• HTTP 프로토콜의 인프라를 그대로 사용할 수 있다.
  • HTTP 표준을 따르는 모든 플랫폼에서 사용할 수 있다.
• 요청이 명확하므로 의도를 쉽게 파악할 수 있다.
• 서버와 클라이언트의 역할이 명확하게 분리된다.

단점

• 표준이 없다.
• 구형 브라우저가 제대로 지원안해주는 경우가 있다.

REST API / RESTful API

REST 기반으로 조건이 잘 지켜져 구현된 API를 뜻한다. 

최근에는 Open API, 마이크로서비스(MSA) 등을 구성할 떄 많이 사용하는 편이다.

 

다음포스트에서는 RESTful하게 설계할 때 고려해야 할 점에 대해 이야기 하겠다.