REST API (자원 중심 API 설계)

한 줄 정의: 웹의 자원(데이터)을 URL로 표현하고, GET·POST·PUT·DELETE 같은 정해진 방식(HTTP 메서드)으로 주고받도록 설계된 API 방식입니다.

쉽게 풀면

REST API는 웹에 있는 모든 것을 '자원(resource)'이라는 명함으로 정리하고, 그 명함마다 고유한 주소(URL)를 붙이는 방식이라고 생각하면 됩니다. 예를 들어 온라인 서점 시스템이 있다면, '책 123번'이라는 자원은 /books/123이라는 주소를 가집니다. 이 책 정보를 보고 싶으면 GET 요청을 보내고, 새 책을 추가하고 싶으면 POST, 정보를 수정하고 싶으면 PUT, 삭제하고 싶으면 DELETE를 보냅니다. 즉 '무엇을(주소)' '어떻게(메서드)' 할지가 명확하게 정해져 있어서, 처음 보는 API라도 규칙만 알면 쉽게 예측하고 사용할 수 있습니다.

왜 중요한가

REST API는 웹 기반 시스템, 모바일 앱, 클라우드 서비스가 서로 데이터를 주고받는 사실상의 표준 방식으로 자리잡았기 때문에, 소프트웨어공학·정보시스템·데이터공학 논문에서 시스템 아키텍처를 설명할 때 빠짐없이 등장합니다. 여러 이질적인 시스템을 느슨하게 결합해 확장 가능한 서비스를 구축하는 마이크로서비스 아키텍처나, 서로 다른 기관의 데이터를 연동하는 오픈데이터·헬스케어 정보시스템 연구에서도 핵심 설계 요소로 다뤄집니다.

논문에서는 이렇게 쓰입니다

"본 연구에서 개발한 시스템은 REST API 형태로 외부 서비스와 데이터를 주고받도록 구현되었다."

이 문장은 소프트웨어공학이나 정보시스템 분야 논문에서, 시스템 간 데이터 연동 방식을 설명할 때 자주 등장합니다. REST API는 표준화된 통신 규칙 덕분에 서로 다른 플랫폼(웹, 모바일 앱, 서버)이 쉽게 데이터를 주고받을 수 있게 해주므로, 연구에서 개발한 시스템의 확장성이나 상호운용성을 강조할 때 근거로 언급됩니다.

"제안된 마이크로서비스 아키텍처는 각 서비스 모듈이 독립적인 REST API(rest api)를 통해 통신하도록 설계되어 서비스 단위의 개별 배포와 확장이 가능하였다."

분산시스템·클라우드컴퓨팅 분야의 예문으로, REST API가 개별 서비스 간 결합도를 낮추어 시스템 유연성을 높이는 설계 원리로 활용됨을 보여줍니다.

"전자의무기록 시스템은 표준화된 REST API(rest api)를 제공하여 서로 다른 병원의 의료정보시스템 간 데이터 상호운용성을 확보하였다."

의료정보학 분야의 예문으로, REST API가 서로 다른 기관 시스템 간 데이터 교환 표준을 제공하는 역할로도 쓰임을 보여줍니다.

조금 더 깊게 보면

REST 아키텍처는 무상태성(statelessness), 자원의 URI를 통한 식별, 표현(representation)을 통한 자원 조작, 캐시 가능성 등 몇 가지 제약 조건을 지킬 때 성립합니다. 이 중 무상태성은 서버가 요청 사이에 클라이언트의 상태를 저장하지 않는다는 뜻으로, 각 요청이 독립적으로 처리되어 시스템 확장이 쉬워지는 장점이 있습니다. 실제 논문에서는 이러한 원칙을 얼마나 충실히 지켰는지, 또는 필요한 데이터만 유연하게 조회할 수 있는 GraphQL 같은 대안 방식과 비교했을 때의 장단점을 함께 논의하는 경우도 있습니다.

주의할 점

REST API라는 이름을 붙였다고 해서 모두 진정한 REST 원칙(무상태성, 자원 중심 설계 등)을 지키는 것은 아닙니다. 실무에서는 이런 원칙을 느슨하게 적용한 경우가 많아 'REST 스러운(RESTful) API' 정도로 부르는 것이 더 정확할 때가 많습니다. 서버와 계속 연결을 유지하며 실시간으로 데이터를 주고받아야 하는 상황에는 REST API보다 웹소켓 (WebSocket)이 더 적합합니다.