REST(Representational State Transfer)는 자원(resource)을 URL로 식별하고 HTTP 메서드로 그 자원에 대한 행위를 표현하는 웹 API 설계 아키텍처 스타일입니다.
특정 프로토콜이나 프레임워크가 아니라 일련의 제약(constraints)이며, 이를 잘 지키면 확장성·캐시 가능성·단순성이 좋아집니다.
핵심 원칙은 이렇습니다. (1) 자원 중심 URL: 동사가 아니라 명사로 자원을 표현합니다(`/users/42`이지 `/getUser?id=42`가 아님). (2) HTTP 메서드의 의미 준수: 조회=GET(safe), 생성=POST, 전체교체=PUT(idempotent), 부분수정=PATCH, 삭제=DELETE(idempotent). 이 계약 덕분에 캐시·재시도·크롤링이 안전하게 동작합니다. (3) 무상태: 각 요청은 필요한 정보를 스스로 담아 서버가 이전 요청을 기억하지 않아도 되게 합니다. (4) 표현 분리: 같은 자원을 JSON·XML 등으로 콘텐츠 협상해 제공합니다.
실무의 대부분 'REST API'는 엄밀한 REST의 일부만 따르는 실용적 절충입니다. 특히 로이 필딩이 강조한 HATEOAS(응답에 다음 행동 링크를 포함해 클라이언트가 하드코딩 없이 API를 탐색)는 잘 지켜지지 않습니다. 상태 코드도 REST 설계의 일부라 성공·클라이언트 오류(4xx)·서버 오류(5xx)를 정확히 써야 합니다. REST의 대안으로 단일 엔드포인트에서 필요한 데이터만 질의하는 GraphQL, 고성능 이진 RPC인 gRPC가 있으며, 각기 트레이드오프가 다릅니다.