RESTful API란 무엇인가?

면접 단골 질문에, 채용 공고에도 많이 써있는 이 API는 왜 써있는 걸까?
내가 프로젝트 하면서 보던 API들이랑은 뭐가 다른건가? 의 궁금증에서 시작된 글 시작~!

RESTful API란?

:REST(Represetational State Transfer) 아키텍처 스타일을 따르는 API
REST는 웹의 기본 프로토콜인 HTTP를 기반으로, 클라이언트와 서버 간의 통신을 효율적으로 하기 위해 정의된 아키텍처 설계원칙이다.

이러한 REST 아키텍처의 설계 원칙은 크게 6가지를 가진다.
이 원칙을 잘 지킨 API를 우린 RESTful API 라고 부른다.

REST 원칙 

1. Uniform Interface(일관된 인터페이스)
2. Stateless(무상태성)
3. Caching(캐싱 가능성)
4. Client-Server(클라이언트-서버 구조)
5. Hierarchical System(계층화된 시스템)
6. Code on Demand(요청에 따른 코드 전송, 선택적)

1. Uniform Interface(일관된 인터페이스)

클라이언트는 URI와 HTTP 메서드를 사용해서 서버의 리소스를 직관적으로 요청하고 관리할 수 있다.

• 리소스 기반 URI: 각 리소스는 고유한 URI로 식별됨
• 표준 HTTP 메서드: CRUD 작업은 HTTP 메서드(GET, POST,,등)으로 명확히 구분된다. 
• 표현의 전송: JSON, XML 같은 리소스 표현을 사용한다. 

2. Stateless(무상태성)

서버가 클라이언트의 상태를 저장하지 않는 원칙
클라이언트의 상태를 저장하지 않고, 요청마다 클라이언트가 자신의 상태 정보를 전송하기 때문에 각각의 요청은 독립적이다. 

• 효율성: 서버가 클라이언트 상태를 기억하지 않으므로 다중 서버로의 확장이 쉬워진다.
• 독립적 요청: 클라이언트의 상태는 매 요청에 포함되므로, 서버는 각 요청을 독립적으로 처리할 수 있다.

3. Caching(캐싱 가능성)

: 캐싱은 동일한 요청이 반복될 때 서버에 부담을 줄이고, 클라이언트의 응답 속도를 높이는데 도움을 준다. 
응답에 캐시 가능한지 여부를 지정할 수 있는 HTTP 헤더가 포함되어야한다. 

• 서버에 재요청하지 않으므로, 네트워크 트래픽 & 서버 로드를 줄일 수 있다. 

Q: 2번의 무상태성에서 클라이언트의 상태를 저장하지않는다고 했는데,, 요청에 대해 무엇을 캐싱하는 걸까?

• 요청이 아닌, 응답을 저장한다.

요청에 대한 리소스 응답을 일정 기간동안 클라이언트/중간 캐시 서버에 저장해둔다.
이후 동일한 요청이 있을 때, 서버가 아닌 캐시에서 응답을 제공하는 것을 의미한다.

Q: 캐시에서 응답을 찾는 것은 어떻게 찾을까?

URI, 캐시 정책을 사용한다.

• URI 사용: 일반적으로, key-value 형태로 저장해 key: URI, value: 저장된 응답 으로 구현된다.
  Ex) 요청 URI: /products/123 면, /products/123 이 key가 된다.
• 캐시정책(Cache-Control, Etag, Expires 등): URI가 일치하는 캐시 항목이 있어도, 응답이 여전히 유효한지 판단하는데 사용된다.
  쉽게 말해, 캐시에 저장할 유효 기간을 정하거나 서버의 리소스가 변경되었는지 판단하는 기능을 한다.

캐시된 응답을 찾기 위해선, 요청 URI와 캐시 정책 둘 다 사용한다.

Ex. 클라이언트가 GET /products/123를 요청한다고 할 때:

1. 먼저 캐시 시스템은 /products/123 URI에 대응하는 캐시된 응답이 있는지 확인합니다.
2. 캐시된 응답이 있으면, 캐시 정책에 따라 유효성 판단을 합니다.
   • 만약 Cache-Control: max-age=3600이라면, 1시간 내에 동일 URI의 요청이 있으면 캐시된 데이터를 그대로 반환합니다.
   • ETag를 사용한 경우, 서버에 If-None-Match 헤더와 함께 요청을 보내고, 서버가 리소스가 변경되지 않았다고 판단하면 304 Not Modified 응답을 보내 캐시된 응답을 재사용할 수 있도록 합니다.

 

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

RESTful 시스템에서 클라이언트-서버의 역할은 명확히 분리되어 있다.

각자의 역할에 집중하기 위해(클라이언트 - 사용자 인터페이스 & 요청)

(서버 - 요청 처리 & 필요한 데이터 제공)

5. Hierarchical System(계층화된 시스템)

여러 계층으로 나누어 확장성과 보안을 높이는 데 중점을 둔다.
계층화된 시스템은 프록시나 게이트웨이를 통해 중개 계층을 두어 확장성과 보안을 강화한다.

클라이언트-서버 사이에 여러 중간 계층을 둘 수 있는데 간접적으로 서버와 상호작용하게 된다.
보안 강화, 성능 최적화, 확장성 향상 등 목적을 위해 사용된다. 
예를 들면, 중간에 프록시 서버/게이트웨이 서버를 클라이언트, 서버의 보안을 강화할 수 있다.

6. Code on Demand(요청에 따른 코드 전송, 선택적)

서버가 클라이언트에 코드를 전송해서 동적으로 기능을 확장할 수 있는 원칙

 

정리

Q: 모든 API가 RESTful 원칙을 사용하는가? 

A: API가 RESTful 한지 확인하는 방법은, 일반적으로 API 문서를 통해 확인 가능하다.
api가 restful api 원칙을 충족해야지만 restful api라고 불리는 것.(얼마나 잘 준수했는지에 따라 RESTful 정도가 달라진다)

주로 아래의 4개 원칙을 잘 준수했는지 문서를 통해 명시할 것이다.

• HTTP 메서드 사용: 문서에 CRUD 작업이 각각 적절한 HTTP 메서드와 URI를 통해 처리되는지
• URI 구조: 리소스 중심의 URI가 명확하게 정의되어 있는지
• 상태 관리: 세션 상태 저장 없이 무상태성을 유지하는지
• 캐싱 여부: Cache-Control, ETag와 같은 캐시 제어 헤더가 설명되어 있는지