REST API란 무엇인가 — 면접에서 제대로 답하기
REST API란 무엇인가, 면접에서 자주 묻는 웹 개념
REST API란 무엇인가는 백엔드·웹 개발 면접의 대표적인 단골 질문입니다. REST(REpresentational State Transfer)는 자원(Resource)을 URI로 표현하고, HTTP 메서드로 그 자원에 대한 행위를 정의하는 아키텍처 스타일입니다. REST 원칙을 잘 지켜 설계한 API를 RESTful API라고 부릅니다. 중요한 건 REST는 '프로토콜'이 아니라 '설계 원칙(스타일)'이라는 점입니다.
REST의 핵심 구성요소
- 자원(Resource): URI로 식별. 예:
/users/1 - 행위(Verb): HTTP 메서드. GET/POST/PUT/PATCH/DELETE
- 표현(Representation): 자원의 상태를 JSON, XML 등으로 주고받음
HTTP 메서드와 행위 매핑
| 메서드 | 의미 | 멱등성 | 안전성 |
|---|---|---|---|
| GET | 자원 조회 | O | O(읽기 전용) |
| POST | 자원 생성 | X | X |
| PUT | 자원 전체 교체/생성 | O | X |
| PATCH | 자원 부분 수정 | X(일반적으로) | X |
| DELETE | 자원 삭제 | O | X |
REST의 6가지 제약 조건
면접에서 깊이를 보여주려면 REST의 제약 조건을 알아야 합니다.
- 클라이언트-서버 구조: 관심사 분리. UI와 데이터 저장을 독립적으로 발전.
- 무상태성(Stateless): 서버는 클라이언트의 상태를 저장하지 않음. 각 요청은 필요한 모든 정보를 담아야 함.
- 캐시 처리(Cacheable): 응답이 캐시 가능한지 명시해 성능 향상.
- 계층화 시스템(Layered System): 클라이언트는 중간 계층(프록시, 게이트웨이)의 존재를 몰라도 됨.
- 인터페이스 일관성(Uniform Interface): 자원 식별, 표현을 통한 조작, 자기 서술적 메시지, HATEOAS.
- 코드 온 디맨드(선택): 서버가 클라이언트에 실행 코드를 전달 가능(유일한 선택적 제약).
무상태성이 왜 중요한가
서버가 클라이언트 상태를 기억하지 않으므로, 어느 서버 인스턴스가 요청을 받아도 동일하게 처리할 수 있습니다. 이는 수평 확장(scale-out)과 로드 밸런싱에 유리합니다. 인증 정보 같은 상태는 매 요청에 토큰(예: JWT)으로 담아 보냅니다.
RESTful URI 설계 규칙
좋은 예
GET /users 사용자 목록 조회
GET /users/1 특정 사용자 조회
POST /users 사용자 생성
PUT /users/1 사용자 전체 수정
DELETE /users/1 사용자 삭제
GET /users/1/orders 특정 사용자의 주문 목록
나쁜 예
GET /getUsers (행위를 URI에 넣음)
POST /users/1/delete (메서드로 표현해야 함)핵심 규칙: URI에는 명사(자원)를, 행위는 HTTP 메서드로 표현합니다. URI는 소문자, 계층은 슬래시로, 동사는 피합니다.
면접 답변 예시
"REST는 자원을 URI로 식별하고 HTTP 메서드로 행위를 표현하는 아키텍처 스타일입니다. 이 원칙을 따른 API가 RESTful API입니다. 자원은 명사로 URI에 표현하고, 조회는 GET, 생성은 POST, 수정은 PUT/PATCH, 삭제는 DELETE로 매핑합니다. REST의 핵심 특징은 무상태성으로, 서버가 클라이언트 상태를 저장하지 않아 수평 확장에 유리합니다. 그 외에도 캐시 가능성, 계층화, 일관된 인터페이스 같은 제약을 따릅니다. 장점은 HTTP 표준을 그대로 활용해 직관적이고 확장성이 좋다는 점이고, 단점은 오버페칭/언더페칭이 생길 수 있어 GraphQL 같은 대안이 등장했습니다."
면접 꼬리질문 대비
Q1. PUT과 PATCH의 차이는?
PUT은 자원 '전체'를 교체합니다. 보낸 표현으로 자원을 덮어쓰므로, 일부 필드를 빼고 보내면 그 필드가 사라질 수 있습니다. PATCH는 '부분' 수정으로 변경할 필드만 보냅니다. 또 PUT은 멱등하지만(같은 요청 여러 번 = 같은 결과), PATCH는 구현에 따라 멱등하지 않을 수 있습니다.
Q2. 멱등성(idempotent)이 무엇이고 왜 중요한가요?
같은 요청을 여러 번 보내도 서버 상태 결과가 동일한 성질입니다. GET, PUT, DELETE는 멱등합니다. 네트워크 오류로 클라이언트가 요청을 재시도해도 안전하게 처리할 수 있어 중요합니다. 반면 POST는 호출할 때마다 새 자원이 생겨 멱등하지 않습니다.
Q3. REST의 한계와 GraphQL의 차이는?
REST는 엔드포인트마다 응답 구조가 고정되어 필요 이상 데이터를 받는 오버페칭, 또는 여러 번 호출해야 하는 언더페칭이 생깁니다. GraphQL은 클라이언트가 필요한 필드만 단일 엔드포인트에서 질의해 이를 해결합니다. 대신 캐싱·복잡도 관리가 어려워, 단순하고 표준적인 경우엔 REST가 여전히 적합합니다.