REST API란?

REST API란

• Representational State Transfer의 약자이다.
• REST 형식의 API를 말한다.
• HTTP프로토콜로 제공하는 API를 REST API라고 한다.
• 핵심 컨텐츠 및 기능을 외부 사이트에서 활용할 수 있도록 제공되는 인터페이스이다.
• 예를 들어, 네이버에서 블로그에 글을 저장하거나, 글 목록을 읽어갈 수 있도록 외부에 기능을 제공하거나 우체국에서 우편 번호를 조회할 수 있는 기능을 제공하거나, 구글에서 구글 지도를 사용할 수 있도록 제공하는 것들을 말한다.
• 서비스 업체들이 다양한 REST API를 제공함으로써, 클라이언트는 이러한 REST API들을 조합한 어플리케이션을 만들 수 있게 되었다. 이를 매시업(Mashup)이라고 한다.
• REST를 논문으로 최초 소개한 로이 필딩은 REST가 다음과 같은 스타일(제약 조건의 집합)을 반드시 지켜야한다고 말한다.
  • cilent-server
  • stateless
  • cache
  • uniform interface
  • layered system
  • code-on-demand(optional)
• HTTP 프로토콜을 사용한다면 client-server, stateless, cache, layered system, code-on-demand 등에 대해서는 쉽게 구현 가능하지만, 문제는 uniform interaface이다. 
• uniform interface의 스타일
  • 리소스가 URI로 식별되야 한다.
  • 리소스를 생성, 수정, 추가하고자 할 때 HTTP 메시지에 표현을 해서 전송해야 한다.
  • 메시지는 스스로 설명할 수 있어야 한다. (Self-descriptive message)
  • 애플리케이션의 상태는 Hyperlink를 이용해 전이되어야 한다.(HATEOAS)
• 첫번째와 두번째 항목은 지키기 어렵지 않지만, 메시지가 스스로 설명할 수 있어야 하는 부분과 HATEOAS를 지원하는 것은 웹과 다르게 API로는 쉽지 않다.
• 또한 응답 결과에 주로 JSON메시지를 사용하게 되는데, 이를 JSON 메시지가 어디에 전달되는지 그리고 JSON 메시지를 구성하는 것이 어떤 의미를 표현해야만 메시지 스스로 설명할 수 있다고 말할 수 있는데, 그게 쉽지 않다.
• 또한 예를 들어 웹 게시판을 사용할 때, 리스트 보기를 보면, 상세보기나 글쓰기로 이동할 수 있는 링크가 있다. 상세 보기에서는 글 수정이나 글 삭제로 갈 수 있는 링크가 있다. 이렇게 웹 페이지를 보면, 웹 페이지 자체에 관련된 링크가 있는 것을 알 수 있는데 이를 HATEOAS라고 한다. 이런 HATEOAS를 API에서 제공하는 것은 쉽지 않다.
• REST API는 쉽지 않다, 그래서 보통은 Web API(혹은 HTTP API)를 사용한다.
  • REST의 uniform interface를 지원하는 것은 쉽지 않기 때문에, 많은 서비스가 REST에서 바라는 것을 모두 지원하지 않고 API를 만들게 된다.
  • REST의 모든 것을 제공하지 않으면서 REST API라고 말하는 경우도 있다.
  • REST의 모든 것을 제공하지 않고 Web API 혹은 HTTP API라고 부르는 경우가 있다.

참조 URL

• https://www.edwith.org/boostcourse-web/lecture/16740/