REST API란 무엇인가

웹에서 앱과 서버가 데이터를 주고받는 거의 모든 장면 뒤에는 정해진 약속이 있다. 모바일 앱이 날씨를 불러오고, 쇼핑몰이 결제를 처리하고, 챗봇이 외부 도구를 호출하는 일까지 — 그 통신의 기본 문법이 바로 REST API다. 이름은 자주 듣지만 “정확히 무엇이고, 왜 표준이 됐는지” 설명하라면 막막해지는 경우가 많다. 이 글은 REST의 정의와 6가지 제약 조건, HTTP 메서드와 CRUD의 매핑, 엔드포인트 설계 원칙, 그리고 GraphQL·gRPC와의 차이까지 입문자 눈높이에서 한 번에 정리한다. 끝까지 읽으면 남이 만든 REST API 문서를 읽고 직접 설계 기준을 세우는 데 필요한 개념이 손에 잡힐 것이다.

REST는 Representational State Transfer의 약자로, 우리말로 옮기면 “표현 상태 전이”다. 2000년 로이 필딩(Roy Fielding)이 박사 학위 논문에서 처음 정의한 아키텍처 스타일로, 그는 HTTP/1.1 명세 작성에도 참여한 인물이다. 즉 REST는 특정 기술이나 라이브러리가 아니라, 웹이 이미 잘 작동하는 방식(HTTP)을 그대로 따르도록 만든 설계 원칙의 묶음이다.

REST API는 이 REST 원칙을 지키는 API를 말한다. 핵심 아이디어는 단순하다. 서버가 다루는 모든 것을 자원(resource) 으로 보고, 각 자원에 고유한 주소(URI)를 부여한 뒤, 그 자원을 HTTP 메서드로 조작한다는 것이다. 예를 들어 /users/42라는 주소는 “42번 사용자”라는 자원을 가리키고, 이 주소에 어떤 HTTP 메서드를 보내느냐에 따라 조회·수정·삭제가 결정된다.

레드햇 문서는 REST의 제약을 따르는 API를 “RESTful API”라고 부르며, REST를 “개발자가 다양한 통신 방식을 구현할 수 있게 하는 유연한 가이드라인”이라고 설명한다. 비유하자면 REST는 도로교통법과 비슷하다. 차종이나 브랜드를 강제하지는 않지만, “빨간불에 멈춘다” 같은 공통 규칙을 모두가 지키기 때문에 처음 보는 도시에서도 운전할 수 있다. REST API도 같은 규칙을 공유하기에, 처음 보는 서비스의 API라도 문서만 보면 대략 작동 방식을 짐작할 수 있다.

REST의 6가지 아키텍처 제약

필딩의 논문은 REST를 6가지 제약 조건으로 정의한다. 이 조건을 충분히 만족하는 API라야 진짜 “RESTful”하다고 부를 수 있다. AWS 설명과 IBM 정리를 기준으로 핵심만 추리면 다음과 같다.

클라이언트-서버 분리(Client-Server) — 화면을 그리는 쪽(클라이언트)과 데이터를 책임지는 쪽(서버)을 분리한다. 양쪽이 독립적으로 발전할 수 있어 유지보수가 쉬워진다.
무상태성(Stateless) — 서버는 각 요청을 이전 요청과 무관하게 독립적으로 처리한다. 요청에 필요한 정보는 매번 그 요청 안에 모두 담겨야 한다. 서버가 “방금 누가 로그인했더라” 같은 상태를 기억하지 않으므로 확장이 쉽다.
캐시 가능(Cacheable) — 응답은 자신이 캐시 가능한지 아닌지를 명시한다. 자주 바뀌지 않는 데이터를 캐시하면 불필요한 통신을 줄일 수 있다.
계층화 시스템(Layered System) — 클라이언트는 자신이 최종 서버와 직접 통신하는지, 중간의 로드밸런서·게이트웨이를 거치는지 알 필요가 없다. 중간 계층을 자유롭게 끼워 넣을 수 있다.
통일된 인터페이스(Uniform Interface) — REST의 핵심 제약이다. 자원은 URI로 식별하고, 표준 메서드로 조작하며, 응답 메시지는 그 자체로 의미를 설명한다(self-descriptive).
코드 온 디맨드(Code on Demand) — 서버가 클라이언트로 실행 가능한 코드(예: 자바스크립트)를 내려보내 기능을 확장한다. 이 항목만 선택 사항이고, 나머지 5개는 필수다.

여기서 현실적인 고백을 하나 덧붙이면, 실무에서 마주치는 상당수의 “REST API”는 이 6가지를 100% 지키지 않는다. 특히 통일된 인터페이스의 마지막 단계인 HATEOAS(응답에 다음 행동 링크를 담는 것)는 구현 비용이 커서 생략되는 경우가 흔하다. 그래서 학계에서는 이런 API를 엄밀히는 “REST를 지향하는(REST-ish)” API라고 부르기도 한다.

HTTP 메서드와 CRUD의 매핑

REST의 동작은 결국 HTTP 메서드로 표현된다. 데이터 처리의 기본 동작인 생성·조회·수정·삭제(CRUD)는 다음 메서드에 자연스럽게 대응한다.

HTTP 메서드	CRUD	역할	멱등성
`GET`	Read	자원 조회 (서버 상태 변경 없음)	O
`POST`	Create	새 자원 생성	X
`PUT`	Update	자원 전체 교체	O
`PATCH`	Update	자원 일부 수정	X
`DELETE`	Delete	자원 삭제	O

여기서 멱등성(idempotency) 은 “같은 요청을 여러 번 보내도 결과가 같다”는 성질이다. DELETE /users/42를 한 번 보내든 세 번 보내든 42번 사용자가 사라진다는 결과는 동일하므로 멱등하다. 반면 POST는 보낼 때마다 새 자원이 생기므로 멱등하지 않다. 네트워크가 불안정해 요청을 재시도해야 할 때 이 차이는 중요하다. 각 메서드의 정확한 의미는 MDN의 HTTP 메서드 문서에 정리돼 있다.

응답에는 항상 HTTP 상태 코드가 따라온다. 주요 코드만 알아 둬도 디버깅이 한결 수월하다.

200 OK — 요청 성공
201 Created — 새 자원 생성 성공 (보통 POST 응답)
400 Bad Request — 클라이언트의 요청 형식 오류
401 Unauthorized / 403 Forbidden — 인증 실패 / 권한 없음
404 Not Found — 자원이 존재하지 않음
500 Internal Server Error — 서버 내부 오류

REST API 요청과 응답 예시

개념을 코드로 보면 더 분명해진다. 아래는 “글 목록 중 7번 게시글을 조회”하는 전형적인 요청과 응답이다.

GET /api/posts/7 HTTP/1.1
Host: example.com
Accept: application/json
Authorization: Bearer eyJhbGciOi...

HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 7,
  "title": "REST API 입문",
  "author": "itinsights",
  "createdAt": "2026-06-19T09:00:00Z"
}

새 게시글을 만들 때는 POST로 본문(body)에 데이터를 담아 보낸다.

POST /api/posts HTTP/1.1
Content-Type: application/json

{ "title": "새 글", "content": "본문 내용" }

서버는 자원을 만든 뒤 201 Created와 함께 새로 생긴 자원의 주소를 Location 헤더로 돌려준다. 이렇게 요청은 동사(메서드) + 명사(URI) + 데이터(본문) 의 조합으로 일관되게 표현된다. 이 일관성이야말로 처음 보는 서비스의 API에도 개발자가 빠르게 적응하게 만드는 힘이다.

좋은 엔드포인트·리소스 설계 원칙

API의 주소 체계, 즉 API 엔드포인트 설계는 REST API의 품질을 좌우한다. 마이크로소프트의 API 설계 가이드가 권하는 관례를 요약하면 다음과 같다.

명사로, 복수형으로: 행위가 아니라 자원을 표현한다. /getUsers(X) → /users(O). 동사는 HTTP 메서드가 이미 표현한다.
계층은 경로로: “3번 사용자의 주문 목록”은 /users/3/orders처럼 자원 간 관계를 경로로 나타낸다.
필터·정렬·페이징은 쿼리스트링으로: /posts?status=published&sort=-createdAt&page=2.
버전을 명시: /v1/users처럼 버전을 경로에 두면 이후 호환성 깨짐을 관리하기 쉽다.
소문자와 하이픈: /userProfiles보다 /user-profiles가 가독성과 일관성에서 유리하다.

이런 규칙은 강제는 아니지만, 팀 전체가 공유하면 API 문서를 보지 않고도 주소를 짐작할 수 있는 수준의 예측 가능성을 만들어 낸다. 실제로 잘 설계된 API는 “주소만 봐도 무엇을 하는지 알겠다”는 평가를 받는다.

REST API vs GraphQL vs gRPC

REST가 사실상의 표준이지만 유일한 선택지는 아니다. 2010년대 중반 이후 등장한 GraphQL과 gRPC는 REST의 약점을 겨냥했다. 세 방식의 성격을 비교하면 다음과 같다.

구분	REST	GraphQL	gRPC
형태	자원 기반 HTTP API	클라이언트 주도 쿼리 언어	고성능 바이너리 RPC
데이터 형식	주로 JSON	JSON	Protocol Buffers(바이너리)
강점	단순함·범용성·캐시	필요한 데이터만 정확히 요청	빠른 속도·실시간 스트리밍
약점	오버페칭/언더페칭	캐싱·러닝커브	브라우저 직접 호출 제약
주 용도	공개 API·CRUD 백엔드	복잡한 프런트엔드 데이터	내부 마이크로서비스

REST의 대표적 약점으로 꼽히는 것이 오버페칭(over-fetching) 과 언더페칭(under-fetching) 이다. 화면에 이름 하나만 필요한데 사용자 정보 전체를 받아 오거나(오버페칭), 반대로 화면 하나를 그리려고 여러 엔드포인트를 연달아 호출해야 하는(언더페칭) 비효율이다. GraphQL은 클라이언트가 필요한 필드만 콕 집어 요청하게 해 이 문제를 해결한다. 반대로 gRPC는 바이너리 직렬화로 서버 간 통신 속도를 끌어올린다.

그렇다면 무엇을 골라야 할까? 업계의 대체적인 합의는 “상황에 맞게”다. 여러 기술 분석이 2026년 시점에도 REST가 공개 API 영역에서 압도적 다수를 차지한다고 본다(다만 구체 점유율 수치는 출처마다 편차가 커 단정하기 어렵다). 복잡한 데이터 요구가 있는 프런트엔드라면 GraphQL을, 지연 시간이 민감한 내부 서비스라면 gRPC를 얹는 하이브리드 구성이 현실적인 정답으로 자리 잡았다. 세 방식의 트레이드오프는 따로 다룰 가치가 있어, 다음 용어집 글에서 GraphQL을 단독으로 더 깊이 파고들 예정이다.

REST API의 한계, 그리고 언제 써야 하나

정리하면, REST API는 웹의 작동 방식을 그대로 활용해 단순하고 범용적인 통신을 가능하게 하는 아키텍처 스타일이다. 배우기 쉽고, 거의 모든 언어와 도구가 지원하며, HTTP 캐시·상태 코드 같은 웹 인프라를 공짜로 누린다는 점이 가장 큰 강점이다.

물론 만능은 아니다. 한 화면을 위해 여러 번 호출해야 하는 언더페칭, 엄격한 타입 규약의 부재, 실시간 양방향 통신의 약함 등은 분명한 한계다. 그럼에도 “처음 만드는 공개 API”나 “표준적인 CRUD 백엔드”라면 2026년에도 REST가 가장 안전하고 무난한 출발점이라는 데 큰 이견은 없다. AI 시대의 새로운 연결 표준인 MCP 프로토콜이나, API를 적극적으로 소비하는 Next.js 15 같은 프레임워크를 이해할 때도 REST의 사고방식이 바탕이 된다.

여러분이 지금 설계 중인 서비스는 어떤 통신이 필요한가? 단순한 자원 조회가 대부분이라면 REST로 충분하고, 데이터 요구가 복잡하거나 성능이 절박하다면 GraphQL·gRPC를 검토할 차례다. 중요한 것은 유행이 아니라 트레이드오프를 아는 것이다. 도구·환경에 따라 최적의 선택은 달라질 수 있으니, 본 정리는 판단의 출발점으로 활용하길 권한다.

REST API란 무엇인가 — 6대 제약과 HTTP 메서드 완전 정리