Spring 기반 REST API

백기선님의 강의인 Spring 기반 REST API 개발 강의를 듣고 공부한 내용을 정리한 글

REST API란 무엇인가?

API는 Application Programming Interface의 약자이다.

REST는 Representational State Transfer의 줄임말이다.

로이 필딩이 개발하였으며 인터넷 상의 시스템 간의 상호 운용성을 제공하는 방법 중 하나이다.

로이 필딩은 많은 개발자들이 HTTP를 잘못사용하는 것을 보고 안타까워 박사논문으로 REST에 관한 논문을 작성하면서 세상에 처음 알려지게 되었다.

REST는 시스템 제각각의 독립적인 진화를 보장하기 위한 방법을 위해 등장하였다.

그래서 이러한 REST의 규약을 따르는 API를 REST API라고 부른다.

그러나 오늘날 REST API는 대부분 REST API라고 할 수 없다.

왜?

REST API라고 부를려면 아래의 아키텍처 스타일을 따라야하는데 대부분의 REST API는 아래의 아키텍처 스타일을 따르지 않는다.

• Client-Server

• Stateless

• Cache

• Uniform Interface

• Layered System

• Code-On-Demand

특히 이중에서도 Uniform Interface를 구성하는 네가지 구성 요소 중 Self-descriptive message와 Hypermisa as the egine of application state(HATEOAS)를 만족하지 않는다.

Self-descriptive message

메시지 스스로가 자신에 대한 설명이 가능해야한다.

서버가 메시지를 바꾸더라도 클라이언트는 바뀐 메시지의 내용을 해석할 수 있어야 한다.

왜? 메시지를 해석할 수 있는 정보가 메시지 안에 존재하기 때문이다.

그러나 오늘날 REST API는 Self-descriptive message를 만족하고 있지 않다.

HATEOAS

응답에 하이퍼미디어가 포함이 되어있어야한다.

그리고 그 하이퍼미디어(링크)를 통해 애플리케이션 상태 변화가 가능해야 한다.

즉, 예를 들어 우리가 유튜브 메인화면에서 영상을 보기 위해 영상을 클릭하면 영상을 볼 수 있듯이

다음 애플리케이션 상태로 전이하기 위해 서버가 보내준 응답의 하이퍼링크를 사용해서 이동을 해야한다는 것이다. (물론 이는 서버,클라이언트에 모두 해당하는 이야기다.)

응답에는 애플리케이션의 상태를 변화시킬 수 있는 하이퍼미디어 정보가 함께 동봉되어야한다.

그렇다면 어떻게 이 두 가지를 만족시킬 수 있을까?

Self-descriptive message 해결 방법

• 미디어 타입을 정의하고 IANA에 등록하고 그 미디어 타입을 리소스 리턴할 때 Content-type으로 사용한다.

• profile 링크 헤더를 추가한다.

  • 브라우저들이 아직 스펙 지원을 잘안한다.
  • 그래서 본문에 profile과 링크를 HAL 스펙에 따라 추가

HATEOAS 해결 방법

• 데이터에 링크 제공
  • HAL 사용 (Hypertext Application Language)

네이버의 API

네이버 클로바의 REST API(라고 주장)를 보도록 하자.

안타깝게도 위의 구조로는 메시지에서 스스로 묘사하는 Self-descriptive message 하지도 않고, 애플리케이션 다음 상태로 이전할 수 있는 HATEOAS 또한 만족하지 않는다.

이러한 API는 REST API라고 부르지 않으며, 일반적으로는 HTTP API 또는 웹 API라고 부르는게 맞다.

카카오의 API

그렇다면 우리 카카오는 어떨까?

REST API라고 제공하고 있지만 카카오페이의 API들은 REST의 규약을 지키지 않고 있다.

역시나 Self-descriptive message를 만족하지 못했고, 다음 상태로 전이하는 HATEOAS 또한 만족하지 못했다.

그러면 도대체 REST API를 만족하는 API는 어떤 API인가!?

Github의 API

결론부터 말하자면 Github의 REST API는 완벽하게 REST의 규약을 지킨 API이다.

Self-descriptive message를 만족하기 위해 헤더에 응답에 대한 미디어 타입을 정의하고 각각의 응답에 대한 메시지를 정의하게 하였다.

위에서 설명한 첫번째 방법이다.

응답의 내용 또한 url을 동봉함으로써 애플리케이션이 다른 상태로 전이할 수 있게 하는 HATEOAS 또한 만족하는 것을 볼 수 있다.

기본적으로 github의 RESTAPI는 응답에 굉장히 많은 url이 있는 것을 확인할 수 있다.

이 REST API를 소비하는 클라이언트는 url을 외울 필요 없이 응답의 본문만으로 HATEOAS를 만족할 수 있다.

이것이 REST API의 정석이다.

결론

이 강의를 듣고 나니 REST API의 정의를 제대로 알고 사용했다고 생각했는데, 그렇지 않았다는 것을 알게 되었다.

단순히 자원과 메소드를 사용해서 정의하는 것을 REST API라고만 알고 있었는데, Self-descriptive message와 HATEOAS를 만족해야한다는 사실을 미처 알지 못했다.

지금까지 참된 REST API란 무엇인지에 대해 살펴보았다.

이제부터 실질적으로 REST API의 규약에 따라 만들어보도록 하자.

Reference

인프런 백기선님의 스프링 부트 개념과 활용