ActiveResource란?
ActiveResource는 RESTful 서비스와 상호작용하기 위한 API 래퍼로, 개발자에게 ActiveRecord와 유사한 경험을 제공했습니다. 이는 리소스에 대한 CRUD(생성, 읽기, 업데이트, 삭제) 주기와 기본 및 토큰 인증을 지원했습니다. 각 API 리소스에 대해 클래스를 생성하고 self.site
, self.auth_type
, self.bearer_token
과 같은 클래스 변수를 지정하여 사용할 수 있었습니다. 예를 들어, Blog
클래스를 ActiveResource::Base를 상속받아 정의하면, 마치 ActiveRecord 모델처럼 find
, save
, destroy
와 같은 메서드를 통해 원격 리소스를 조회, 업데이트, 삭제할 수 있었습니다. ActiveResource는 API로부터 JSON 응답을 기대하며, 반환된 JSON 객체의 각 요소를 객체의 속성으로 설정하여 개발자가 쉽게 데이터를 다룰 수 있게 했습니다. 이는 API와의 상호작용을 매우 ‘Rails스러운’ 방식으로 간소화한 유용한 라이브러리였습니다.
Rails에서 제외된 이유
ActiveResource는 Rails 4.0 버전에서 Rails 코어 코드에서 공식적으로 제거되었습니다. 공식적인 이유는 유지보수 부족과 코어 Rails 팀 내 전담 유지보수자의 부재였습니다. 비공식적으로는 라이브러리 자체의 여러 문제점과 함께 RestClient, HTTParty와 같은 다른 강력한 HTTP 클라이언트 라이브러리들의 부상도 큰 영향을 미쳤습니다. 이들 대안 라이브러리들은 개발자들이 ActiveResource의 제약 없이 API와 보다 유연하게 커스텀 통합을 설정할 수 있도록 해주었습니다.
문제점
ActiveResource가 널리 사용되지 않게 된 가장 큰 이유는 REST API가 따라야 할 확고한 규칙이 없다는 점 때문입니다. HTTP API 환경은 ‘와일드 웨스트’와 같아서, 모범 사례는 존재하지만 이를 강제하는 메커니즘은 없습니다. 이는 ActiveRecord가 정의된 언어(SQL)를 통해 데이터베이스와 통신하여 개발자에게 부담을 주지 않으면서도 강력한 의견을 가질 수 있는 것과는 대조적입니다. ActiveResource는 ActiveRecord의 동작을 모방하려 했지만, REST API의 비표준화된 특성 때문에 예상되는 동작에 대한 사용자 정의가 필요할 때마다 한계에 부딪혔습니다. 즉, ActiveResource는 이상적인 환경(예: 내부적으로 양쪽 끝을 모두 제어할 수 있는 API)에서는 매우 유용했지만, 다양한 외부 API의 비표준화된 요구사항을 충족시키기에는 역부족이었습니다. 개발자들은 ActiveResource의 부족한 부분을 직접 채워야 했고, 이는 결국 더 유연한 대안을 찾게 만들었습니다.