030 | REST API

💙API & REST

🤍 API(Application Programming Interface)

• 특정 서비스를 제공하기 위한 프로그래밍 세트로 사용할 수 있는 프로그래밍 인터페이스 목록을 호출해서 사용
• 웹 앱을 구현하는데 네이버 로그인을 해야되는 상황이라고 했을 때, 네이버에서 제공하는 OpenAPI를 통해 네이버의 로그인 기능을 호출하여 연동할 수 있음

🤍 REST(Representational State Transfer)

• REST는 월드 와이드 웹과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식으로, 자원을 이름(자원의 표현)으로 구분하여 해당 자원의 상태(정보)를 주고 받는 모든 것을 의미함
• 쉽게 말해 API를 구축할때 URI와 HTTP Method를 활용하여 API의 기능을 추측 가능하게끔 아키텍쳐를 구성하는 원칙같은 것이다. REST 원칙을 잘 따른 API만이 RESTful API라는 영광을 얻을 수 있는 것이다. 아 이 API는 RESTful하구나~ 하는 것이란 얘기다.

🤍 REST 구성

• 자원 (Resource) - URI
  모든 리소스는 고유한 주소가 존재하고, 서버에 존재함. URI를 통해 리소스를 구분하고 호출
• 행위 (Verb) - HTTP Method
  CRUD에 맞춰 HTTP Method 설정
• 표현 (Representation of Resource)
  브라우저와 웹 서버간 데이터를 주고받는 형태 (ex. JSON, XML, TEXT, RSS, ...)

🤍 REST Architectural Constraints

RESTful 아키텍처에는 6가지 설계 원칙은 로이 필딩이 2000년 논문에서 기술했다고 한다.

1. 서버-클라이언트 구조 (Server-Client)

• REST 아키텍처의 기초
• 일반적인 서버와 클라이언트 구조를 띄며, 일정한 인터페이스를 통해 연결됨

 

2. 무상태 (Stateless)

• HTTP 프로토콜을 사용하기 때문에 HTTP의 특징인 무상태성을 가짐
• 서버 상태의 관리가 없음을 인지하고 있어야 함
• 각 클라이언트 요청은 이전에 클라이언트가 요청한 모든 요청과 무관하며, 클라이언트가 보낸 요청에는 해당 요청을 처리하기 위해 서버가 필요로 하는 모든 정보가 있어야 함

3. 캐시 처리 가능 (Cacheable / Cashing)

• HTTP 프로토콜에서 사용하는 Last-Modified Tag 또는 E-Tag를 이용해 캐싱을 지원
• Stateless의 부정적인 영향 중 일부는 캐싱으로 조절 가능
• 캐시를 위한 REST 아키텍처 제약 조건 서버가 응답을 캐시 가능 또는 캐시 불가능으로 표시해야되며, 캐시는 HTTP 헤더를 통해 서버에 의해 제어됨

4. 계층화 (Layered System)

• REST API 아키텍처가 여러 계층으로 구성되어야 함
• 아키텍처 내 각 계층은 다른 계층과 독립적으로 변경될 수 있음
• 클라이언트, 서버로만 구성할 수 도 있고 중간에 Gateway나 프록시 서버와 같은 미들 웨어를 배치해 계층화할 수 있음

5. 인터페이스 일관성 (Uniform Interface)

• URI로 지정한 리소스에 대한 요청을 통일되고, 한정적으로 수행하는 아키텍처 스타일을 의미한다.
• 클라이언트와 서버가 공통으로 기술적인 인터페이스를 갖고 있는 것
• 여기서 인터페이스는 클라이언트와 서버 간 통신을 위한 약속이고, 이 약속은 HTTP 메서드와 미디어 유형을 사용하여 정의되고, 이것의 장점은 아키텍처를 분리한다.
• 균일한 인터페이스의 제약 조건 4가지
  • 리소스 IDIdentity of the resource(URI/URL)
  • 자원의 표현(Representation of the resource)
  • 자체 설명 메시지(Self descriptive messages — metadata)
  • 하이퍼미디어(Hypermedia

6. 자체 표현 (Self-Descriptiveness)

• URI만 분석해도 무슨 기능인지 유추가 된다는 특성이다.

✅ Ref.

Is the Richardson Maturity Model Relevant in 2019.

🤍 REST API

• REST 원칙 기반 구현 API
• 웹(http)의 장점을 최대한 활용할 수 있는 아키텍처
• 웹에서 사용되는 데이터나 자원을 HTTP URI로 표현하고, HTTP 프로토콜을 통해 요청과 응답을 정의하는 방식

💙 Richardson Maturity Model (RMM)

Leonard Richardson이 100개의 다른 웹 서비스 디자인을 분석하고 이러한 디자인을 4개의 범주로 나눴다. 이 범주는 웹 서비스가 얼마나 REST를 따르는지를 기초로 하는데, 이 REST 서비스 분할 모델을 RMM(Richardson Maturity Model)이라고 한다.

Richardson은 서비스의 성숙도를 결정하기 위해 세 가지 주요 요소(⇒ URI, HTTP 메서드, HATEOAS(하이퍼미디어))를 사용했다. 서비스가 이 요소를 더 많이 사용할수록 더 성숙해지는 것으로 간주한다.

REST 성숙도 모델 - 0단계

• 0단계에서는 단순히 HTTP 프로토콜을 사용하기만 하면 됨
• 이런 경우에는 해당 API를 REST API라고 할 수는 없으며, 0단계는 좋은 REST API를 작성하기 위한 기본 단계
• HTTP or RPC(Remote Procedure Call) 사용
• 단일 URI를 가지며, 단일 HTTP 메서드(일반적으로 POST) 사용

REST 성숙도 모델 -1단계

• URI 사용 / HTTP, HATEOAS 사용 안함
• 개별 리소스와의 통신을 준수해야하며, 많은 URI를 사용하지만 일반적으로 HTTP POST 사용
• 이 서비스는 시스템에서 사용할 수 있는 각 리소스에 고유한 URI를 제공하는데, 고유한 URI는 하나의 고유한 리소스를 별도로 식별함

REST 성숙도 모델 - 2단계

• URI, HTTP 사용 / HATEOAS 사용 안함
• 일반적으로 수많은 URI(주소 지정 가능한 리소스) 호스팅
• CRUD에 맞게 적절한 HTTP 메서드를 사용하는 것에 중점을 둠

REST 성숙도 모델 - 3단계

• Richardson의 가장 마지막 모델
• URI, HTTP, HATEOAS(Hypertext As The Engine Of Application state) 세 가지 모두 사용
• HATEOAS: API 클라이언트의 상호작용을 주도하는 리소스의 응답 메시지에 포함된 요소
• 3단계에서 개발된 API는 일반적으로 완전한 RESTful API로 간주됨

✅ Ref.

Richardson Maturity Model