쉬운 설명
REST의 핵심 아이디어는 '서비스를 자원(resource)의 모음으로 본다'는 것입니다. 사용자·게시글·댓글이 모두 자원이고, 각각 고유한 주소(예: /users/123, /posts/456)를 가집니다. 그 주소에 GET을 보내면 읽고, POST는 새로 만들고, PUT은 수정, DELETE는 삭제하는 식으로 동작이 표준화됩니다.
이 단순한 규칙 덕분에 새 API 문서를 처음 보는 개발자도 '아 이 자원에 이 메서드를 보내면 이게 되겠구나'라고 빠르게 짐작할 수 있습니다. 또 같은 도구·캐시·인증 메커니즘을 여러 API에 그대로 쓸 수 있어 생태계가 풍부합니다.
REST는 단순한 형태이지만 약속이 꽤 있습니다. ① 자원 중심 URL(예: /users/123/posts/456), ② 동사는 HTTP 메서드로(URL에는 동사를 넣지 않음), ③ 상태 코드로 결과 표시(200 OK, 404 Not Found, 500 Server Error), ④ 응답·요청 본문은 보통 JSON, ⑤ 같은 요청은 같은 결과(GET은 부작용이 없어야 함). 이 약속을 잘 지킬수록 API가 '예상 가능'해지고 도구가 잘 어울립니다.
REST와 자주 비교되는 GraphQL은 '클라이언트가 원하는 모양을 정해 받는다'는 발상으로 REST의 일부 불편함(여러 번 호출, 과다 응답)을 해결합니다. 그러나 REST는 여전히 가장 흔한 API 스타일이고, 모바일 앱·웹·외부 연동·공공 데이터 포털 등 표준에 가깝습니다. 단순한 시스템에는 REST가 가장 가볍습니다.
주의할 점도 있습니다. REST는 한 화면이 여러 자원을 동시에 필요로 하면 호출이 많아져 모바일 환경에서 느려질 수 있습니다. 또 자원 관계가 복잡하면 URL이 길어지고, 버전 관리(예: /v1/users → /v2/users)가 까다로워집니다. 그래서 회사 규모가 커지면 REST를 기본으로 두고 GraphQL이나 gRPC를 일부 영역에 함께 쓰는 경우가 많습니다.
비유로 보면
REST는 도서관의 청구 기호 시스템과 비슷합니다. 책마다 고유 번호가 있어 그 번호를 알면 어느 서가의 어떤 자리에 있는지 즉시 찾을 수 있습니다. '빌리기·반납·조회' 같은 동작도 동일한 절차로 표준화돼 있어, 사서가 바뀌어도 같은 방식으로 일이 돌아갑니다.
어디에서 만나나
공공 데이터 포털(국가의 거의 모든 공공 API가 REST), 결제·지도·로그인·알림 외부 API의 대부분, 사내 마이크로서비스 사이의 통신, 그리고 거의 모든 SaaS의 공개 API. 모바일 앱·웹·서드파티 연동의 표준에 가깝습니다.
작은 예시
블로그 API라면 GET /posts로 글 목록, GET /posts/42로 42번 글, POST /posts로 새 글 작성, DELETE /posts/42로 삭제가 됩니다. 처음 보는 API라도 이 패턴만 알면 문서 없이 어느 정도 사용법이 짐작됩니다.
자주 하는 오해
한 줄 정리
REST의 가치는 '예상 가능함'입니다. 잘 만든 REST API는 문서를 깊이 읽지 않아도 다음에 무슨 호출이 가능할지가 자연스럽게 떠오릅니다.