Является ли ActiveResource принципиально ошибочным?

Несколько разработчиков из разных групп самостоятельно сказали мне, что ActiveResource является ошибочной идеей. Самая распространенная критика, которую я слышу, заключается в том, что было ошибкой придумать интерфейс ActiveRecord. Я также слышу жалобы на то, как обрабатываются ошибки, или проглатывается. Один разработчик фактически создал свой собственный камень для обеспечения той же функциональности, что и ActiveResource (фреймворк для моделей, основанных на ресурсах RESTful).

Я новичок в ActiveResource, но когда я смотрю на код и экспериментирую и вижу, как это работает, я изо всех сил стараюсь понять, откуда идет сопротивление. Кажется, он основан на чистых, твердых концепциях. Я даже слышал, что это слишком тяжело! Но в моем исследовании я нахожу его легким и быстрым.

Итак, со всеми этими спорами об ActiveResource, я обратился к Интернету за ответами. Разумеется, должны быть стеки сообщений в блогах о том, почему ActiveResource следует консервировать в пользу X. В конце концов, я уверен, что найду сообщения о том, превосходит ли DataMapper ActiveRecord. Поэтому я обыскал, и я искал и... ничего. Ничего. Я не могу найти ни одну страницу в Интернете, критикующую ActiveResource (кроме общей критики REST). Я даже не могу найти предложенную альтернативу. Он имеет поддержку основной команды Rails и, по-видимому, является стандартом де-факто в сообществе.

Нижняя строка:

Есть ли спор о ActiveResource? И если да, то в чем суть дебатов? Существуют ли альтернативы?

Ответ 1

Я активно работал с ActiveResource с 2007 года и создал и поддерживал распределенную архитектуру с несколькими сервисами, используя ARes за период, когда Rails перешел от версии с 1.2 до версии 4.0. По моему мнению, ARes в корне ошибочен как публичная библиотека в ее нынешней форме, но содержит много хороших идей, которые можно использовать в отдельных системах. Я дал беседу о том, что мы сделали в моей компании, чтобы перейти от ARes.

Большая причина, по которой люди не любят ARes на практике, из-за плохого обслуживания или деталей реализации, с которыми они не согласны. Такие вещи, как сообщение об ошибке с вашим коллегой, относятся к этой категории. Кроме того, со временем вы обнаружите, что неожиданно неожиданно возникли проблемы из-за ненадежных одноразовых улучшений или исправлений ошибок или даже с внутренними изменениями Rails (например, когда YAML-pocalypse ударил в прошлом году, мы пострадали от катастрофического разрушения в наших системах ARes). Но все это можно улучшить, улучшив обслуживание и улучшив зрение, важно отделить эти проблемы от фундаментальной проблемы.

То, во что я верил, и то, что Иегуда намекает в своем комментарии выше, заключается в том, что ARes терпит неудачу, потому что REST API не имеют общей конкретной семантики. Даже используя лучшие из правил Rails, семантика HTTP API в лучшем случае надуманна.

Сравните это с тем, что делает ActiveRecord, он генерирует SQL: четко определенный декларативный язык для выбора строк данных. SQL основан на реляционной модели, которая дает нам математические определения того, что означает запрос, основанный на разных предложениях. Это математическое обоснование - это то, что позволяет что-то вроде Arel создавать композитный SQL DSL в рубине. В базе данных SQL любой синтаксически правильный запрос может быть выполнен (даже если он слишком медленный, чтобы быть практичным), потому что движок предназначен для формального анализа и сопоставления операторов SQL, чтобы обеспечить правильную реализацию, которая манипулирует и извлекает базовые данные. Поэтому, когда вы создаете ORM, например ActiveRecord, у вас есть очень сильные гарантии в базовой системе. Если вы создаете правильный SQL, двигатель гарантирует, что он будет работать, если вы создадите недопустимый SQL, то двигатель вернет вам ошибку. И даже при стандартизации SQL стоит отметить, что каждая база данных имеет отдельный адаптер ActiveRecord, чтобы обеспечить правильность и правильное отображение функций ActiveRecord. Каждый из них использует базовый драйвер для обеспечения правильной проводной реализации протокола для текущей базы данных. Весь этот код имеет довольно большое количество спецификаций и обслуживания позади него, все из которых обеспечивают доброкачественную элегантность и надежность сегодняшнего ActiveRecord.

Теперь рассмотрим API HTTP и его поддержку? Это может быть любая технология базы данных под солнцем или вообще нет! Он, скорее всего, написан на собственном языке и обслуживает только то, что необходимо для бизнес-функции. В отличие от базы данных, которая содержит в своей схеме всю необходимую информацию о работе общих запросов, HTTP API полностью отделен от любого основного механизма хранения или бизнес-логики. Даже если API предоставляет стандарт для того, как он использует параметры запроса, нет самодокументированного определения того, какой фильтр или параметры сортировки доступны. Черт, даже проверка правильности параметров не гарантируется, так же часто, как не API, просто проглотит или проигнорирует недопустимый параметр.

Все, что сказал, ARes очень удобно, но оно построено на зыбучих песках. Идеи и соглашения, которые он использует, удобны, но им не хватает сплоченного видения и стабильности, чтобы быть надежным. Лично я думаю, что катит ваш ARes похожим на свои собственные соглашения и твердые спецификации, которые вы затем можете применить к реализации вашего сервиса, не является необоснованным.

С точки зрения построения фундамента, поверх которого может быть что-то вроде ARes, Yehuda Katz и Steve Klabnik отлично спецификация JSON: API отличный проект сообщества, который обеспечит один очень важный строительный блок такого фундамента, однако стоит отметить, что он по-прежнему не находится рядом с конкретным драйвером базы данных с точки зрения семантических гарантий и выводимых функциональных возможностей. Я подозреваю, что действительно хорошая ARes-подобная библиотека для использования JSON-API будет существенно отличаться от того, что она делает сегодня, чтобы лучше охватить серые области, неявные в adhoc API, по сравнению с РСУБД.

Изменить: JSON: API только что ударил 1.0 после очень интенсивных двух лет дебатов и отзывов от разных сообществ. Я бы оценил объем работы, введенной в эту спецификацию, на пару порядков больше, чем когда-либо достигнутый ActiveResource. Хотя он отличается от уровня ActiveResource от уровня абстракции, JSON: API преследует аналогичную цель - предоставлять стандартную семантику, чтобы API-интерфейсы легче обрабатывать и потреблять. Глядя на некоторые из implementations, дает хорошее представление о том, сколько средств может предоставить JSON: API.

Ответ 2

ActiveResource был извлечен из Rails в Rails 4.0.

Многие люди просто используют RestClient или HTTParty или другую библиотеку. Эти библиотеки обычно считаются более простыми и удобными в использовании.