REST API는 단순히 URL 주소를 예쁘게 만드는 것 이상의 의미를 가집니다. 핵심은 "HTTP 프로토콜의 장점을 최대한 활용하여, 자원(Resource)을 이름으로 구분하고 그 상태를 주고받는 아키텍처 스타일"입니다. 오늘은 백엔드 개발자의 기본 소양인 REST API의 구성 요소와 주요 특징, 그리고 왜 우리가 RESTful한 설계를 지향해야 하는지 정리해 보겠습니다.
REST는 크게 세 가지 구성 요소로 이루어집니다. 이를 적절하게 조합했을 때 비로소 'RESTful'한 API가 탄생합니다.
| 요소 | 설명 | 표현 방식 |
|---|---|---|
| 자원(Resource) | 관리 대상 모두 (사용자, 게시글 등) | URI (예: /users, /posts) |
| 행위 (Verb) | 자원에 대해 수행하려는 작업 | HTTP Method (GET, POST, PUT, DELETE) |
| 표현 (Representation) | 자원의 상태를 어떻게 전달할 것인가 | JSON, XML (최근에는 JSON이 표준) |
"그냥 URL에 동사를 써서 /getUser라고 하면 안 되나요?"라는 의문이 생길 수 있습니다. 하지만 REST의 특징을 이해하면 왜 이런 규칙들이 필요한지 알 수 있습니다.
1) 무상태성 (Stateless) 서버는 클라이언트의 상태를 기억하지 않습니다. 각 요청은 독립적이며, 필요한 모든 정보를 담고 있어야 합니다. 덕분에 서버의 부담이 줄어들고 확장성이 높아집니다.
2) 클라이언트-서버 구조 (Client-Server Architecture) 자원을 가진 쪽(Server)과 요청하는 쪽(Client)의 역할을 확실히 분리합니다. 이 덕분에 서로 간의 의존성이 줄어들고 독립적인 진화가 가능해집니다.
3) 캐시 처리 가능 (Cacheable) HTTP라는 기존 웹 표준을 그대로 사용하기 때문에, 브라우저나 프록시 서버의 캐싱 기능을 활용할 수 있습니다. 대량의 트래픽을 효율적으로 처리할 수 있는 비결이죠.
4) 계층화 (Layered System) 클라이언트는 서버가 직접 통신하는지, 중간에 로드 밸런서나 암호화 계층이 있는지 알 필요가 없습니다. 구조적 유연성을 보장합니다.
5) 인터페이스 일관성 (Uniform Interface) URI로 지정한 자원에 대해 조작할 때, 특정 언어나 플랫폼에 종속되지 않는 공통된 인터페이스를 사용합니다.
개념으로만 듣기보다는 실제 어떻게 자원을 다루는지 보는 것이 좋습니다. 아래는 게시글(posts)이라는 자원을 다루는 설계 예시입니다.
// 1. 게시글 목록 조회 (Read)
GET /posts
// 2. 새로운 게시글 생성 (Create)
POST /posts
{ "title": "안녕하세요", "content": "REST 공부 중입니다." }
// 3. 특정 게시글 수정 (Update)
PUT /posts/1
{ "title": "수정된 제목" }
// 4. 특정 게시글 삭제 (Delete)
DELETE /posts/1여기서 주의! URI에는 deletePosts 같은 동사를 포함하지 않는 것이 원칙입니다. 행위는 HTTP Method가 담당하고, URI는 오직 무엇(자원)인지만 나타내야 하기 때문입니다.
REST API는 단순히 데이터를 주고받는 통로가 아니라, 시스템 간의 약속입니다. 캡슐화가 객체의 독립성을 지켜주듯, REST는 서비스 간의 독립성을 확보해 줍니다.
**자원(URI)**과 **행위(Method)**를 명확히 분리하기
상태를 유지하지 않음으로써 서버의 확장성을 높이기
표준을 준수하여 누구나 쉽게 이해할 수 있는 인터페이스 만들기
제대로 된 RESTful API 설계는 함께 협업하는 프론트엔드 개발자와의 소통을 더욱 원활하게 해주는 백엔드 개발자의 능력이기도 합니다. 우리 모두 명확하고 간결한 API를 설계하는 멋진 아기사자가 되어 봅시다!
댓글 0