[Web] RESTful API

이 글은 「그런 REST API로 괜찮은가」 라는 Naver D2의 유튜브 영상을 매우 많이 참고해서 작성되었다.

 

REST API란 무엇인가?

REST 아키텍쳐 스타일을 따르는 API가 REST API다.

REST를 기반으로 서비스 API를 구현한 것

RESTful하다는 것은 REST API를 제공하는, REST의 스타일을 잘 지키는 시스템을 RESTful하다고 할 수 있다.

 

REST란?

Representational State Tranfer의 약자. 자원을 이름으로 구분하여 해당 자원의 상태를 주고받는 모든 것을 의미한다.

월드 와이드 웹(WWW)과 같은 분산 하이퍼미디어 시스템을 위한 아키텍쳐 스타일.

REST는 네트워크 상에서 Client와 Server 사이의 통신 방식 중 하나로, 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에 웹의 장점을 최대한 활용할 수 있는 아키텍쳐 스타일이다.

API란?

Application Programming Interface의 약자로, 응용 프로그램에서 사용할 수 있도록, 운영체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스를 의미한다.

여기서 "응용 프로그램"이란 우리가 만든 서비스, "운영체제나 프로그래밍 언어가 제공하는 기능"을 네이버 지도, 카카오 로그인, 미세먼지 정보 등과 같은 것이라고 보면 된다.

즉, 프로그램과 또 다른 프로그램을 이어주는 매개체다.

아키텍쳐 스타일이란?

제약조건의 집합.

즉, REST의 제약조건들을 모두 지키면 REST API라 할 수 있다.

 

REST의 구성

REST는 자원(Resource), 행위(Verb), 표현(Representation)으로 구성되어 있다.

• 자원(Resource) - URI
  • 모든 자원에는 고유한 ID가 존재하고, 이 자원은 Serber에 존재한다.
  • 자원을 구분하는 ID는 HTTP다.
  • Client는 URI를 이용해서 자원을 Server에 요청한다.
• 행위 (Verb) = HTTP Method
  • HTTP 프로토콜의 메소드를 사용한다.
  • HTTP 프로토콜은 GET, POST, PUT, DELETE와 같은 메서드를 제공한다.
• 표현 (Representation)
  • Client가 자원의 상태에 대한 조작을 요청하면 Server는 이에 적절한 응답(Representation)을 보낸다.
  • REST에서 하나의 자원은 JSON, XML, TEXT, RSS 등 여러 형태의 Representation으로 나타내어 질 수 있다.

 

REST를 구성하는 스타일

REST는 다음과 같은 특징을 반드시 지켜야 한다.

• client-server 구조
  • 서버는 REST API 제공, 클라이언트는 유저와 관련된 처리 - 사용자 인증이나 Context(세션, 로그인 정보)등을 직접 관리하는 구조로, 각각의 역할이 확실히 구분되기 때문에 서로 개발해야 할 부분이 명확해지고 서로간의 의존성이 줄어들게 된다.
• stateless (무상태성)
  • 상태정보를 따로 관리하고 저장하지 않는다.
  • 세션 정보나 쿠키 정보를  별도로 저장하고 관리하지 않기 때문에 API 서버는 들어오는 요청만 단순히 처리하면 된다. 때문에 서비스의 자유도가 높아지고 서버에서 불필요한 정보를 관리하지 않음으로써 구현이 단순해진다.
• cacheable (캐시 처리 가능)
  • REST는 HTTP라는 기존 웹 표준을 그대로 사용하기 때문에, 웹에서 사용하는 기존 인프라를 그대로 활용이 가능하다. 그래서 HTTP가 가진 캐싱 기능을 적용할 수 있다.
• layered system (계층형 구조)
  • REST 서버는 다중 계층으로 구성될 수 있으며 보안, 로드 밸런싱, 암호화 계층을 추가해 구조상의 유연성을 둘 수 있고 PROXY, 게이트웨이 같은 네트워크 기반의 중간매체를 사용할 수 있게 한다.
• uniform interface (유니폼 인터페이스)
  • uniform interface는 URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍쳐 스타일을 말한다.
• Code on Demand (선택)

Self-descriptiveness (자체 표현 구조)

• REST API 메시지만 보고도 이를 쉽게 이해할 수 있는 자체 표현 구조로 되어있다는 것.
• 영상의 설명에서는 uniform interface의 특성에 속해있다.

 

유투브는 밖의 6가지를 REST의 스타일이라 하고 TOAST나 다른 블로그에는 Code on Demand가 아닌 Serl-descriptiveness를 포함한 6가지를 REST의 스타일이라 한다. 무엇이 맞는 것인지는 잘 모르겠으나 우선 유튜브 영상의 내용을 따른다.

 

★ Uniform Interface (유튜브에서의 설명)

4가지 제약조건으로 이루어져 있다.

• identification of resources : 리소스가 URI로 식별되면 된다.
• manipulation of resources through representations : 리소스를 수정, 삭제, 생성할 때 HTTP 메시지에 표현을 담아서 전송을 해야한다.
• Self-descriptiveness (자체 표현 구조) : 메시지는 스스로를 설명해야 한다.
• hypermedia as engine of application state (HATEOAS) : 애플리케이션의 상태는 Hyperlink를 이용해 전이되어야 한다.

자칭 REST API라고 알려진 모든 것들이 대부분 밑에 두가지 제약조건은 지키지 못하고 있다고 한다.

 

REST의 장단점

장점

• HTTP 프로토콜의 인프라를 그대로 사용하기 때문에 REST API 사용을 위한 별도의 인프라를 구출할 필요가 없다.
• HTTP 프로토콜의 표준을 최대한 활용하여 여러 추가적인 장점을 함께 가져갈 수 있게 해준다.
• HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다.
• REST API 메시지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악할 수 있다.
• 서버와 클라이언트의 역할을 명확하기 분리한다.

단점

• 표준이 존재하지 않는다.
• HTTP Method의 형태가 제한적이다.

 

REST가 필요한 이유

왜 uniform interface가 필요한가.

「독립적 진화」 때문

서버와 클라이언트가 각각 독립적으로 진화하기 때문에 서버의 기능이 변경되어도 클라이언트를 업데이트할 필요가 없다.

REST를 만들게 된 계기: "How do I improve HTTP without breaking Web."  HTTP를 계속 업데이트 해도 웹이 깨지지 않으려면 어떻게 해야 할까?

즉, 독립적 진화를 위해서다. 이 독립적 진화를 만족하려면 반드시 uniform interface가 만족되어야 한다.

 

REST API 설계 규칙 ★★

1. URI는 정보의 자원을 표현해야 한다.

2. 자원에 대한 행위는 HTTP Method (GET, POST, PUT, DELETE)로 표현한다.

 

---

참고 링크

https://www.youtube.com/watch?v=RP_f5dMoHFc&list=WL&index=94&t=0s

https://meetup.toast.com/posts/92

REST API 제대로 알고 사용하기 : TOAST Meetup

https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html

[Network] REST란? REST API란? RESTful이란? - Heee's Development Blog

https://velog.io/@wlsdud2194/HTTP-REST-API-%EB%9E%80

[HTTP] REST API 란