REST API (자원 중심 API 설계)
쉽게 풀면
REST API는 웹에 있는 모든 것을 '자원(resource)'이라는 명함으로 정리하고, 그 명함마다 고유한 주소(URL)를 붙이는 방식이라고 생각하면 됩니다. 예를 들어 온라인 서점 시스템이 있다면, '책 123번'이라는 자원은 /books/123이라는 주소를 가집니다.
이 책 정보를 보고 싶으면 GET 요청을 보내고, 새 책을 추가하고 싶으면 POST, 정보를 수정하고 싶으면 PUT, 삭제하고 싶으면 DELETE를 보냅니다. 즉 '무엇을(주소)' '어떻게(메서드)' 할지가 명확하게 정해져 있어서, 처음 보는 API라도 규칙만 알면 쉽게 예측하고 사용할 수 있습니다.
왜 중요한가
REST API는 웹 기반 시스템, 모바일 앱, 클라우드 서비스가 서로 데이터를 주고받는 사실상의 표준 방식으로 자리잡았기 때문에, 소프트웨어공학·정보시스템·데이터공학 논문에서 시스템 아키텍처를 설명할 때 빠짐없이 등장합니다. 여러 이질적인 시스템을 느슨하게 결합해 확장 가능한 서비스를 구축하는 마이크로서비스 아키텍처나, 서로 다른 기관의 데이터를 연동하는 오픈데이터·헬스케어 정보시스템 연구에서도 핵심 설계 요소로 다뤄집니다.
핵심 정리
REST(Representational State Transfer)는 Fielding(2000)이 박사학위 논문에서 웹의 구조를 설명하며 정리한 아키텍처 스타일입니다. 프로토콜이나 표준 규격이 아니라 “이런 제약을 지키면 웹처럼 확장되기 쉽다”는 설계 원칙의 묶음입니다. 이 원칙을 따르는 웹 API를 REST API라고 부릅니다.
| 제약 | 뜻 |
|---|---|
| 클라이언트-서버 | 화면(클라이언트)과 데이터 저장(서버)의 관심사를 분리 |
| 무상태성 | 각 요청에 처리에 필요한 정보가 모두 들어 있고, 서버는 요청 사이의 세션 상태를 기억하지 않음 |
| 캐시 가능성 | 응답이 캐시 가능한지 표시해 중복 요청을 줄임 |
| 균일한 인터페이스 | 자원 식별(URI), 표현을 통한 조작, 자기 서술적 메시지, 하이퍼미디어 연결 |
| 계층화된 시스템 | 중간 서버(프록시, 게이트웨이)가 있어도 클라이언트가 알 필요 없음 |
| 코드 온디맨드(선택) | 서버가 실행 가능한 코드를 내려보내 기능을 확장 |
HTTP 메서드의 성질도 알아 두면 좋습니다. HTTP 의미 규격(RFC 9110)에서 GET은 서버 상태를 바꾸지 않는 안전한 메서드이고, GET·PUT·DELETE는 같은 요청을 여러 번 보내도 결과가 같은 멱등 메서드입니다. POST는 일반적으로 멱등이 아닙니다.
예시로 보기
온라인 서점을 예로 들면 다음처럼 설계합니다(가상의 예).
| 하려는 일 | 요청 | 흔한 성공 응답 |
|---|---|---|
| 책 목록 조회 | GET /books | 200 OK |
| 123번 책 조회 | GET /books/123 | 200 OK, 없으면 404 Not Found |
| 새 책 등록 | POST /books | 201 Created(새 자원의 주소를 함께 알려 줌) |
| 123번 책 수정(전체 교체) | PUT /books/123 | 200 OK 또는 204 No Content |
| 123번 책 삭제 | DELETE /books/123 | 204 No Content |
주소는 “무엇”(자원)을, 메서드는 “무엇을 한다”를 나타내므로 /getBook이나 /deleteBook처럼 동사를 주소에 넣지 않는 것이 REST 스타일의 관례입니다. 연구에서는 서비스 설계 사례나 시스템 구현을 서술할 때 이런 구조를 표로 제시합니다.
자주 하는 오해
| 오해 | 바로잡기 |
|---|---|
| JSON으로 응답하면 REST다. | 데이터 형식은 REST의 제약이 아닙니다. XML이나 HTML도 표현이 될 수 있습니다. |
| REST는 HTTP와 같은 말이다. | REST는 설계 원칙이고 HTTP는 그것을 구현하는 데 쓰는 프로토콜입니다. 웹이 REST의 대표 사례일 뿐입니다. |
| URL이 /books/123 모양이면 REST API다. | 이 페이지가 말하듯 이름만 REST인 API가 많습니다. 균일한 인터페이스의 하이퍼미디어 요소(응답 안에 다음에 할 수 있는 동작의 링크를 담는 것)까지 지키는 API는 드뭅니다. ‘REST 스러운(RESTful)’이라는 표현이 더 정확할 때가 많습니다. |
| 무상태성은 서버에 데이터를 저장하지 않는다는 뜻이다. | 자원의 상태(DB의 데이터)는 저장합니다. 없어야 하는 것은 요청 사이의 세션 상태입니다. |
| 항상 REST가 최선이다. | 서버가 계속 연결을 유지하며 실시간으로 밀어 보내야 한다면 웹소켓이 더 맞고, 필요한 필드만 골라 받고 싶다면 GraphQL이 대안입니다. |
논문에서는 이렇게 쓰입니다
실제 논문에서
이 용어를 직접 쓴 국내 논문 문장을 아직 수집하지 못했습니다. 수집되는 대로 출처와 함께 싣겠습니다.
예시 문장
아래는 용어의 쓰임을 보여 주려고 만든 예시로, 실제 논문에서 가져온 문장이 아닙니다.
이 문장은 소프트웨어공학이나 정보시스템 분야 논문에서, 시스템 간 데이터 연동 방식을 설명할 때 자주 등장합니다. REST API는 표준화된 통신 규칙 덕분에 서로 다른 플랫폼(웹, 모바일 앱, 서버)이 쉽게 데이터를 주고받을 수 있게 해주므로, 연구에서 개발한 시스템의 확장성이나 상호운용성을 강조할 때 근거로 언급됩니다.
분산시스템·클라우드컴퓨팅 분야의 예문으로, REST API가 개별 서비스 간 결합도를 낮추어 시스템 유연성을 높이는 설계 원리로 활용됨을 보여줍니다.
의료정보학 분야의 예문으로, REST API가 서로 다른 기관 시스템 간 데이터 교환 표준을 제공하는 역할로도 쓰임을 보여줍니다.
조금 더 깊게 보면
REST 아키텍처는 무상태성(statelessness), 자원의 URI를 통한 식별, 표현(representation)을 통한 자원 조작, 캐시 가능성 등 몇 가지 제약 조건을 지킬 때 성립합니다.
이 중 무상태성은 서버가 요청 사이에 클라이언트의 상태를 저장하지 않는다는 뜻으로, 각 요청이 독립적으로 처리되어 시스템 확장이 쉬워지는 장점이 있습니다.
실제 논문에서는 이러한 원칙을 얼마나 충실히 지켰는지, 또는 필요한 데이터만 유연하게 조회할 수 있는 GraphQL 같은 대안 방식과 비교했을 때의 장단점을 함께 논의하는 경우도 있습니다.
주의할 점
REST API라는 이름을 붙였다고 해서 모두 진정한 REST 원칙(무상태성, 자원 중심 설계 등)을 지키는 것은 아닙니다. 실무에서는 이런 원칙을 느슨하게 적용한 경우가 많아 'REST 스러운(RESTful) API' 정도로 부르는 것이 더 정확할 때가 많습니다. 서버와 계속 연결을 유지하며 실시간으로 데이터를 주고받아야 하는 상황에는 REST API보다 웹소켓 (WebSocket)이 더 적합합니다.
헷갈리기 쉬운 용어
| 용어 | 한 줄 설명 | REST API와의 차이 |
|---|---|---|
| GraphQL | 클라이언트가 필요한 데이터 구조를 질의로 지정하는 쿼리 언어 | 보통 단일 주소로 질의를 보내며 자원별 주소+메서드 구조가 아님 |
| 웹소켓 | 연결을 유지한 채 양방향으로 실시간 통신 | 요청-응답으로 끝나는 무상태 구조가 아님 |
| SOAP | XML 메시지 형식과 규약을 정의한 웹 서비스 프로토콜 | 규약이 정해진 프로토콜이고 REST는 스타일 |
참고 문헌
- Fielding, R. T. (2000). Architectural styles and the design of network-based software architectures [Doctoral dissertation]. University of California, Irvine.
- Fielding, R., Nottingham, M., & Reschke, J. (Eds.). (2022). HTTP semantics (RFC 9110). Internet Engineering Task Force.
- Richardson, L., & Ruby, S. (2007). RESTful web services. O'Reilly Media.
표의 기준값은 위 문헌에 근거한 관례이며, 분야·학술지마다 다른 기준을 쓸 수 있습니다.