서론
REST (Representational State Transfer)는 분산 시스템에서 다른 구성 요소 간의 통신과 상호 작용을 설계하기 위한 아키텍처 스타일입니다. RESTful API는 이러한 가이드라인과 원칙을 따르는 API입니다.
이용준 개발자님이 발표하신 유튜브 영상
(https://www.youtube.com/watch?v=RP_f5dMoHFc)
을 시청하고 완벽한 REST API 설계는 없다, 즉 역시 은총알은 없다는 것을 다시금 느꼈습니다.
완벽한 API는 없지만, 완벽에 가까운 REST 스타일의 API를 만들기 위해 HTTP 프로토콜에 대해 공부하고 스펙을 적절히 활용하고 API 설계 컨벤션에 대해 고민해야겠습니다.
본론
REST 아키텍처의 주요 원칙은 다음과 같습니다 :
1. Uniform Interface (일관된 인터페이스)
RESTful API에서는 고유한 URI (Uniform Resource Identifier)를 사용하여 자원을 식별합니다. 이는 개념적인 대상이며 이름을 가질 수 있는 정보를 나타냅니다. 또한, 자원의 생성, 수정, 삭제와 같은 상태 변화를 표현할 수 있습니다.
2. manipulation of resources through representations (표현을 통한 자원 조작)
자원에 대한 조작은 해당 자원의 표현을 통해 이루어집니다. RESTful API는 특정 상태의 자원을 나타내는 표현을 사용하여 자원을 조작합니다.
3. self-descriptive messages (자기 서술적 메시지)
RESTful API는 메시지 자체에 포함된 정보를 통해 메시지를 이해할 수 있도록 합니다. 이는 HTTP 메서드, 헤더, 상태 코드 등을 활용하여 메시지를 자기 서술적으로 만듭니다.
4. HATEOAS (hypermedia as the engine of application state)
HATEOAS는 애플리케이션의 상태를 나타내는 역할로써, hypermedia 링크를 통해 API의 다양한 상태와 관련 리소스에 접근할 수 있도록 합니다. 이를 통해 클라이언트는 리소스를 찾고 조작하는 데 필요한 모든 정보를 얻을 수 있습니다. 이는 '어플리케이션의 상태가 Hyperlink를 이용해 전이되어야 한다'라는 의미합니다. 우리의 API는 미디어 타입이 주로 JSON(JSON 형식의 데이터를 위주로 주고받는 형태)인데, HATEOAS를 지키기 어렵습니다.
백엔드와 프론트엔드의 분리
백엔드에는 애플리케이션의 핵심 비즈니스 로직이 포함됩니다. 서버 측에서 로직을 중앙 집중화함으로써 일관성과 유지 관리성을 보장할 수 있습니다. 또한, 프론트엔드에 민감한 비즈니스 규칙과 알고리즘을 노출시키지 않아 조작이나 오용으로부터 안전성을 높입니다.
프론트엔드와 백엔드를 분리함으로써 각 구성 요소를 독립적으로 진화할 수 있습니다.
여기서 진화란 잦은 클라이언트 업데이트 없이도 백엔드와 프론트엔드의 독립적인 확장을 의미합니다.
백엔드는 복잡한 데이터 처리, 데이터베이스 작업, 성능 최적화와 같은 작업을 처리하고, 프론트엔드는 반응성 있는 사용자 인터페이스를 제공하는 데 집중할 수 있습니다. 이 분리를 통해 자원 할당과 확장성을 효율적으로 관리할 수 있습니다.
결론
REST API가 명시하는 모든 원칙을 만족하는 API를 작성하는 것은 쉽지 않습니다. REST의 self-descriptive와 HATEOAS 원칙은 만족하기 정말 어렵습니다.
그렇지만 API가 꼭 REST API여야 할 필요가 없습니다.
굳이 REST API를 구현하고 싶다면 마이크로소프트 사에서 만든 REST API 가이드라인(https://github.com/microsoft/api-guidelines/blob/vNext/Guidelines.md)을 참조하여 완벽에 가까운 API를 설계할 수 있도록 노력해야겠습니다.
참고
