그런 REST API로 괜찮은가
RESTful API는 소프트웨어 개발에서 많이 사용되는 용어이다. 나도 컴퓨터공학 기초를 배울 때 대략적으로만 배웠을 뿐, 자세히 설명할 수 없었다.
회사에서 프론트엔드 개발자로 일하면서, 내부 API가 일관성과 직관성이 부족하다는 느낌을 받았다. 하지만, RESTful한 API가 무엇인지 몰라서 개선 방법을 요구할 수 없었다.
그러던 중에 네이버 개발자 컨퍼런스에서 발표된 REST API에 대한 영상을 보고, REST API의 의미와 원칙이 도움이 될 것이라 생각하여 더 자세히 알고 싶어졌다. 이 영상에서는 RESTful API가 무엇인지부터, 어떻게 그 철학을 추구할 수 있는지까지 설명하고 있으므로, 참고하면 좋을 것 같다.
네이버 컨퍼런스 - Day1, 2-2. 그런 REST API로 괜찮은가
REST는 무엇인가
REST는 REpresentational State Transfer의 약어이고, 이를 나름대로 번역하여 추상적 상태 이전 으로 이해하고 있다.
이것만 봐서는 어떤 용어인지 파악하기 어렵다. Roy Fielding이라는 개발자의 글에서 보는 것이 그 설명이 가장 순수하지 않을까 생각하여 그의 글을 참고했다. 하지만, 보기 좋게 정리된 것은 아니라 IBM에서 REST API를 설명한 문서를 참고했다.
SOAP 또는 XML-RPC 등의 일부 API는 개발자에 대한 엄격한 프레임워크를 부과합니다. 그러나 REST API는 거의 모든 프로그래밍 언어를 사용하여 개발이 가능하며, 다양한 데이터 포맷을 지원할 수 있습니다. 유일한 요구사항은 이들이 아키텍처 제한사항으로도 알려진 다음의 6가지 REST 디자인 원칙에 맞아야 한다는 것입니다.
REST API 디자인을 위한 6가지 제한 조건은 다음과 같습니다.
- 균일한 인터페이스: 모든 API 요청이 동일한 리소스에 접근할 때, 항상 동일한 모습을 제공해야 합니다.
- 클라이언트-서버 디커플링: 클라이언트와 서버 애플리케이션은 서로 완전히 독립적이어야 합니다.
- 상태 없음: REST API는 상태를 유지하지 않습니다.
- 캐싱: 가능한 경우, REST API는 클라이언트나 서버측에서 리소스를 캐싱할 수 있어야 합니다.
- 계층 구조 아키텍처: REST API에서는 호출과 응답이 서로 다른 계층을 통과합니다.
- 코드 온디맨드 (옵션): REST API는 일반적으로 정적 리소스를 전송하지만, 특정한 경우에는 응답에 실행 코드를 포함할 수 있습니다.
-IBM -
이러한 REST API 디자인 제한 조건은 서버와 클라이언트 간의 통신을 단순화하고, 확장성을 높이며, 보안성을 강화하는 등 다양한 이점을 제공한다.
더 자세한 내용은 IBM의 REST API 소개 글을 참고하면 될 거 같다.
RESTful API의 장점
- 다양한 클라이언트 지원: RESTful한 API는 거의 모든 프로그래밍 언어를 사용하여 개발이 가능하다. 또한, 다양한 데이터 포맷을 지원할 수 있다.
- 확장성: RESTful한 API는 캐시 처리 가능, 계층 구조 아키텍처 등 다양한 제한조건을 충족시키므로, 확장성이 높다.
- 간편한 사용: RESTful한 API의 구성 요소 인터페이스는 HTTP GET, POST, DELETE 등과 같은 표준 HTTP 메서드와 연계되어 있으므로, 사용이 편하다.
RESTful API의 단점
- 초기 투자비가 큼: RESTful한 API를 구현할 때는 일부 제한조건을 충족시키기 위한 추가적인 작업이 필요하다. 이로 인해 초기 투자 리소스가 크게 요구될 수 있다.
- 설계의 복잡성: RESTful한 API는 제한조건을 충족시키면서 설계가 복잡해질 수 있다.
- 유지보수가 어려울 수 있음: 다양한 클라이언트를 지원하기 위해 다양한 데이터 포맷을 지원한다. 이로 인해 유지보수가 어려울 수 있다.
원칙을 지키지 않았을 때 발생할 수 있는 이슈
RESTful API는 일관성과 직관성을 제공하기 위해 일부 제한조건을 충족시켜야 한다. 제한조건을 충족시키지 않은 API는 일관성이 떨어지고 이해하기 어려울 수 있기때문이다. 또한, RESTful한 API의 장점 중 하나는 확장성이 높다는 것인데, 제한조건을 지키지 않은 API는 확장성이 떨어질 수 있다. 따라서, RESTful API를 지향하지만, 일부 제한조건을 지키지 않았을 때 발생할 수 있는 이슈를 인식하고, 필요에 따라 제한조건을 조정해 한다.
꼭 RESTful API를 선택해야하는가?
RESTful한 API를 선택해야 할지 여부는 조직의 상황에 따라 다르다. RESTful한 API를 구현하기 위해서는 일부 제한조건을 충족시켜야 하므로 초기 투자비가 크게 들 수 있으며, 설계가 복잡해질 수 있다.
또한, 다양한 클라이언트를 지원하기 위해 다양한 데이터 포맷을 지원하므로 유지보수가 어려울 수 있다.
하지만, RESTful한 API는 거의 모든 프로그래밍 언어를 사용하여 개발이 가능하고, 다양한 제한조건을 충족시켜 확장성을 높일 수 있으며, 캐시 처리 가능, 계층 구조 아키텍처 등 다양한 제한조건을 충족시켜 보안성을 높일 수 있어 매우 유용하다.
따라서, RESTful API를 구현함에서 얻는 이점과 그것을 구현하기 위해 드는 리소스를 비교하여 조직의 상황에 맞게 조정하는 것이 가장 좋은 약속이라고 할 수 있을 것이다. RESTful한 것을 간단하게 구현할 수 있는 통신 API라고 착각한 나머지 기본 원칙이 제대로 지켜지지 않고 있거나, 조직의 상황에 맞지 않다면 다른 방식의 API를 선택하는 것도 한 가지 방법이다.
결국은 약속
기술은 항상 대체될 가능성이 있다. 개발자는 하나의 기술만 믿지 않고 장단점과 트레이드 오프를 고려해야 한다. RESTful API도 마찬가지다.
대부분의 팀에서 RESTful API를 중요하게 생각한다. RESTful API는 위에서 언급한대로 장점이 있다. 그러나, RESTful한 API를 구현하기 위해 필요한 기본 원칙이 지켜지지 않고 있거나, 정확히 무엇인지 모르고 사용하는 경우가 많다.
또한, 조직에서 RESTful API가 꼭 필요한지 다시 생각해 볼 필요가 있다. REST를 지켜서 Roy Fielding 이 인정하는 RESTful한 API를 만드는 것에서 얻는 이점과 그것을 구현하기 위해 조직에서 사용하는 리소스를 비교해 보아야 할 것이다.
조직의 여건이 마땅치 않아 RESTful API를 정확히 구현할 수 없지만, 구성원이 API를 보고 어떤 것인지 알 수 있는 시스템 및 팀 내 규칙이 갖춰져 있다면, RESTful API는 선택 사항이 될 수 있다. REST API 설계의 본질은 자유롭지 못한 규약에서 얻는 일관성에 있다고 생각한다. 자유로운 것과 통제성이 높은 것은 반대되는 것이지만, 극단으로 치우치면 어떤 쪽이더라도 장기적으로는 좋지 않다. 각각의 장단점을 파악하고 수용하여 중간 지점에서 조직의 상황에 맞게 조정하는 것이 가장 좋은 방법이라고 생각한다.
단순히 RESTful API를 구현해야만 좋은 설계라는 생각을 버리고, RESTful API가 항상 필요한 것은 아님을 인지하는 것이 더 효율적이고 생산적일 수 있다. 이를 위해, 개발자는 속한 조직에 대해 더 깊이 이해하고, 그에 맞는 최선의 방법을 찾아 나서야 한다.
참고자료
