Restful API?

Restful API 백엔드를 공부한다면 정말 많이 접해봤을 것이다.

 

아니 분명 API 는 많이 들어봤는데 Restful API 는 무엇일까.

 

Restful API 란?

Restful API(Representational State Transferful API)는 웹 서비스 간의 통신을 위한 소프트웨어 아키텍처 스타일 중 하나이다. RESTful API는 리소스(자원)에 대한 표현을 전송하고, 이 리소스에 대한 CRUD(Create, Read, Update, Delete) 작업을 HTTP 프로토콜을 통해 수행하는 방식으로 작동한다.

 

정말 이해하기 어렵게 정의가 되어있다.

 

쉽게 말하자면 이렇다. Rest의 원리를 따르는 API 라고 생각하면 된다. 즉, 이쁜 API를 만드는 원리를 따르는 API 로 보자.

 

API는 비유를 하자면 음식점의 홀서빙 직원이라고 생각하면 된다.

손님(클라이언트) 음식점(홈페이지)에 들어간다.

홀서빙직원(API) 이 와서 무슨 메뉴(요청)를 원하는지 물어보고 손님은 홀서빙 직원(API) 에게 원하는 메뉴(요청)를 말한다.

그러면 홀서빙 직원(API)는 주방장(서버) 에게 손님(클라이언트)가 원하는 메뉴(요청)을 전달한다.

주방장(서버)는 음식(응답)을 만들어서 홀서빙 직원(API)에게 주고 손님(클라이언트)에게 전달하라고 한다.

그럼 홀서빙 직원(API)는 손님(클라이언트) 에게 음식(응답) 을 전달한다.

 

그러면 API가 대체 뭘까? 우리는 API를 사실 굉장히 많이 봤다.

const express = require('express')   // 라이브러리 불러오는 코드
const app = express() // 라이브러리 불러오는 코드

app.get('/', function (req, res) {        // 이게 API 이다!!!!!!!
  res.send('Hello World')
})

app.listen(3000)  // 서버를 띄우는 코드

 

저렇게 app.get 으로 써 놓은 코드가 바로 API 이다.

 

그러면 이제 이쁜 API를 만드는 원리인 Rest의 원리가 무엇일까? 

 

Rest의 원리란?

1) 클라이언트-서버 아키텍처(Client-Server Architecture):

클라이언트와 서버의 역할을 명확히 분리한다. 클라이언트는 사용자 인터페이스 및 사용자 경험을 책임지며, 서버는 데이터 저장 및 비즈니스 로직을 관리한다. 이렇게 역할을 분리함으로써 각 구성 요소의 독립성과 확장성이 높아진다.

=> 즉, 클라이언트에게 말 그대로 서버의 역할을 시키면 안된다는 것이다. 위 비유로 따지면, 손님이 음식 만들게 해선 안된다는 것.

 

2) 스테이트리스(Stateless):

각 요청은 독립적이어야 하며, 서버는 이전 요청의 상태를 기억하지 않습니다.

필요한 모든 상태 정보는 클라이언트가 요청에 포함해야 합니다.

이로 인해 서버는 더 단순해지고, 클라이언트와 서버 간의 상호작용이 더 예측 가능해집니다.

=> 즉, 요청은 각각 독립적으로 처리 되어야 한다는 것이다. 서로 의존관계에 놓이면 안 된다는 것.

 

3) 캐시 가능(Cacheable):

응답은 캐시 가능해야 하며, 캐싱 규칙은 명시적으로 정의되어야 한다. 이를 통해 네트워크 트래픽을 줄이고, 응답 시간을 단축할 수 있다.

=> 즉, 캐시가 가능해야 한다. (어차피 캐싱을 자동으로 됨) 자주 쓰이는 자료는 요청을 반복해서 하지 않고 하드에 저장해놓고 쓴다는 것. 위 비유로 따지자면 단골손님이 매번 똑같이 시키는 음식은 그때마다 만드는게 아니라 미리 만들어놓고 주문 할 때마다 준다는 것.

 

4) 일관된 인터페이스(Uniform Interface):

일관된 인터페이스를 제공하여 각 부분이 독립적으로 발전할 수 있게 한다. 이는 RESTful 시스템을 다른 아키텍처 스타일과 구별하는 중요한 제약이다. 일관된 인터페이스는 다음과 같은 요소들로 구성된다.

- 리소스 식별(Resource Identification): URI를 통해 리소스를 고유하게 식별한다.

- 리소스 조작(Resource Manipulation): HTTP 메서드(GET, POST, PUT, DELETE 등)를 통해 리소스를 조작한다.

- 자기 서술적 메시지(Self-Descriptive Messages): 메시지 자체에 필요한 정보를 포함한다.

- HATEOAS(Hypermedia As The Engine Of Application State): 클라이언트는 서버 응답에 포함된 링크를 통해 애플리케이션의 상태를 전이한다.

=> 즉, 아래 예시처럼 일관되게 url을 구성해야한다. = lsiron과 연관된 것이라면 lsiron/1 이런식으로. lsiron과 연관된 것인데 /hello 이런식으로 짜는건 안됨.

추가로 하나의 url은 한 종류의 데이터만 가져올 수 있도록 한다. 

app.get('/lsiron', function (req, res) {        
  res.send('lsiron')
})

app.get('/lsiron/1', function (req, res) {       
  res.send('lsiron1')
})

app.get('/lsiron/2', function (req, res) {       
  res.send('lsiron2')
})

 

5) 계층화 시스템(Layered System):

클라이언트는 중간 서버를 통해 여러 계층에 접근할 수 있습니다.

이는 보안, 로드 밸런싱, 캐싱 등의 기능을 분리하여 시스템의 확장성과 관리 용이성을 높입니다.

=> 요청 하나는 최종 응답 전 까지 여러 단계를 거쳐도 된다. 즉, 요청은 미들웨어 등을 통해 여러 단계를 거쳐도 된다.

 

6) 코드 온 디맨드(Code on Demand, 선택 사항):

서버는 클라이언트에게 코드를 전송하여 실행할 수 있습니다(예: 자바스크립트).

이는 클라이언트 기능을 확장할 수 있는 유연성을 제공합니다.

=> 즉, 서버에서 코드를 클라이언트에게 보내서 실행할 수 있어야함. 

 

이러한 원칙들을 잘 지키면서 만든 서버 API를 Restful API(이쁜 API) 라고 한다.

 

이렇게 이쁜 API (Restful API)를 만들기 위한 규칙이 있다.

 

1. 동사보다 명사위주로 작명한다.

https://www.lsiron.com/lsiron (O)
https://www.lsiron.com/play (X)

 

2. 마지막에 슬래시(/)를 포함하지 않는다.

https://www.lsiron.com/lsiron (O)
https://www.lsiron.com/lsiron/ (X)

 

3. 띄어쓰기는 언더 바(_) 대신 하이픈(-) 을 사용한다.

https://www.lsiron.com/lsiron-page (O)
https://www.lsiron.com/lsiron_page (X)

 

4. 소문자를 사용한다.

https://www.lsiron.com/lsiron (O)
https://www.lsiron.com/LSIRON (X)

 

5. 파일 확장자를 URL에 포함시키지 않는다.

https://www.lsiron.com/lsiron (O)
https://www.lsiron.com/lsiron.html (X)

 

6. 복수형을 사용한다.

https://www.lsiron.com/images (O)
https://www.lsiron.com/image (X)