REST API를 설명할 때 어떤 제약과 실무 계약을 구분해야 하나요?

이렇게 답해 보세요 (핵심 답변)

REST는 자원을 URI로 식별하고 HTTP 메서드(GET, POST, PUT, PATCH, DELETE)로 행위를 나타내며, 클라이언트-서버 분리·무상태성(Stateless)·캐시 가능성·계층화·통일된 인터페이스(Uniform Interface) 같은 아키텍처 제약을 따르는 스타일입니다. 실무에서 흔히 말하는 RESTful HTTP API는 이러한 원칙 중 자원 중심 URI와 HTTP 메서드 의미(안전성·멱등성), 표준 상태 코드(2xx, 4xx, 5xx), 일관된 에러 응답 구조를 계약으로 맞추는 데 집중합니다. 따라서 단순히 JSON을 반환하거나 URL에 명사를 썼다는 것만으로 엄밀한 REST 제약(HATEOAS 등)을 모두 만족하는 것은 아니며, 팀과 클라이언트 간에 명확하고 예측 가능한 API 계약을 유지하는 것이 핵심입니다.

함께 설명하면 좋은 이유 (꼬리질문 대비)

1. REST의 무상태성(Stateless)은 서버에 데이터베이스를 두지 않는다는 뜻이 아니라, 각 HTTP 요청이 그 자체로 요청 처리에 필요한 모든 문맥을 담아야 한다는 뜻입니다.
2. GET·PUT·DELETE처럼 멱등성이 기대되는 메서드와 POST처럼 중복 실행 시 부작용이 생기는 메서드를 구분해야 클라이언트의 자동 재시도 정책을 안전하게 설계할 수 있습니다.

면접에서 자주 하는 실수

REST API는 무조건 JSON만 써야 한다거나, URL 모양만 명사형이면 상태 코드와 메서드 의미를 무시해도 REST라고 설명하는 것은 부정확합니다.