1. RESTful API
REST(Representational State Transfer)는 웹의 기존 인프라를 그대로 활용하기 위해 만들어진 설계 규칙이다. 그리고 이 규칙을 철저하게 지켜서 만든 API를 RESTful API라고 부른다.
가장 쉽게 비유하자면 "전 세계 개발자들이 웹에서 데이터를 주고받기 위해 약속한 표준 문법"이다.
REST API의 3대 구성 요소
REST API는 다음 3가지 요소를 바탕으로 디자인된다.
- 자원 (Resource) ➔ URI: 무엇을 가져올 것인가? (예:
/users,/articles/10) - 행위 (Verb) ➔ HTTP Method: 무엇을 할 것인가? (예:
GET,POST,PUT,DELETE) - 표현 (Representation): 어떤 형태로 보여줄 것인가? (현재는 대부분 JSON을 사용)
// ❌ 잘못된 예시 (행위를 URI에 포함)
POST /delete_user/123
// ⭕ RESTful한 예시 (자원은 URI로, 행위는 HTTP Method로)
DELETE /users/1232. REST의 핵심: 6가지 제약 조건 (Design Principles)
REST 아키텍처 스타일로 인정받기 위해서는 아래 6가지 제약 조건을 만족해야 한다. 이 규칙들을 지킬 때 비로소 확장성 높고 유지보수가 쉬운 API가 완성된다.
① Client-Server (클라이언트-서버 구조)
- 개념: 자원을 가진 쪽(Server)과 요청하는 쪽(Client)의 역할이 명확히 분리되어야 한다.
- 특징: 서버는 비즈니스 로직과 데이터 저장에만 집중하고, 클라이언트는 UI/UX에만 집중한다. 서로 간의 의존성이 줄어들어 독립적인 개발과 진화가 가능해진다.
② Stateless (무상태성)
- 개념: 서버는 클라이언트의 상태(Context)를 기억하지 않는다. 즉, 세션이나 쿠키 정보를 서버에 저장하지 않는다.
- 특징: 클라이언트의 모든 요청은 그 자체로 완벽한 정보를 담고 있어야 한다. 서버가 상태를 관리하지 않으므로, 요청이 급증할 때 서버를 여러 대 늘리는 수평적 확장(Scale-out)이 매우 유리해진다.
③ Cacheable (캐시 가능성)
- 개념: HTTP라는 기존 웹 표준을 그대로 쓰기 때문에, 웹이 가진 강력한 무기인 캐싱을 그대로 활용할 수 있어야 한다.
- 특징:
Cache-Control같은 HTTP 헤더를 활용해 응답 데이터를 캐싱하면, 클라이언트가 서버에 똑같은 요청을 또 보낼 필요 없이 로컬 데이터를 사용한다. 결과적으로 서버 부하가 줄고 응답 속도가 획기적으로 빨라진다.
④ Uniform Interface (일관된 인터페이스)
- 개념: URI로 지정된 자원에 대한 조작이 아키텍처 전체에서 일관되고 단순하게 이루어져야 한다.
- 세부 조건:
- 자원의 식별: 자원은 반드시 URI로 식별되어야 한다.
- 표현을 통한 자원 조작: 클라이언트가 JSON 등 자원의 표현을 가지고 있다면 이를 수정/삭제할 수 있는 충분한 정보를 가진 것이다.
- 자기 서술적 메시지 (Self-descriptive): 메시지 본문만 보고도 해석이 가능해야 한다 (예:
Content-Type: application/json명시). - HATEOAS: 응답 데이터에 다음 단계로 갈 수 있는 링크(URI)를 동적으로 포함해야 한다.
⑤ Layered System (계층화 시스템)
- 개념: 클라이언트는 자신이 서버에 직접 붙었는지, 중간에 무언가를 거쳤는지 알 수 없어야 한다.
- 특징: 중간에 로드 밸런서, 방화벽, 암호화 계층(SSL), 캐시 서버 등을 자유롭게 배치할 수 있다. 클라이언트 코드의 수정 없이도 전체 시스템의 보안성과 대규모 트래픽 처리 능력을 높일 수 있는 비결이다.
⑥ Code on Demand (주문형 코드)
- 개념: 서버가 클라이언트에게 실행 가능한 코드(예: JavaScript 스크립트)를 직접 내려주어 클라이언트 기능을 일시적으로 확장하는 것이다.
- 특징: 6가지 조건 중 유일하게 필수 사항이 아니다. 최근 모바일 앱 환경이나 보안상의 이유로 현대 REST API에서는 거의 사용되지 않는다.
내 꿈은 풀스택 개발자