ActiveResource ожидает, что эта конечная точка вернет данные в очень специфическом формате.
Долгое время мы использовали ActiveResource в моей компании для взаимодействия между приложениями. Однако в последнее время мы начали склоняться к HTTParty, потому что он выполняет намного меньше магии вуду и, как правило, является очень небольшим упражнением в выдергивании волос.
Вот пример того, как мы сейчас используем HTTParty:
module CoreResources
class Job
include HTTParty
base_uri Rails.configuration.core_resource_uri
basic_auth Rails.configuration.core_resource_user, Rails.configuration.core_resource_password
def self.search(entity)
get("/api/v1/jobs.json", :query => {:entity_id => entity.id})
end
def self.find(id)
result = get("/api/v1/jobs/#{id}.json")
raise CoreResources::JobNotFound.new if result.response.code == "404"
raise "Unexpected response from resource job find: #{result.response.code} #{result.response.to_s}" if result.response.code =~ /^(?:4|5)..$/
result
end
end
end
Проблема с ActiveResource заключается в том, что он берет очень специально созданную разметку json или xml и создает на ее основе объекты ActiveResource и вложенные объекты. У него возникают проблемы с вызовом collect, потому что что-то в ответе json должно было быть отформатировано как перечислимое, а не (вероятно, родительский узел должен был быть массивом или чем-то, не уверен), что заставляет его взрываться.
С HTTParty вы получаете для работы коллекцию, проанализированную json.
Мне достаточно легко сделать это:
jobs = CoreResources::Job.search(my_entity)
puts jobs.inspect
# [{
# "id" => 4,
# "created_by_id" => 12,
# "description" => "I like pie"
# },
# {
# "id" => 5",
# "created_by_id" => 12,
# "description" => "Mmm, cake"
# }]
Который позволяет мне получать доступ к заданиям через простой массив / хэш-конструкцию jobs[0].fetch("description"), в отличие от ActiveResource: jobs[0].description. ActiveResource медленнее уничтожает эти коллекции, излишне забирает у них память и рекомендует вам дублировать код, который должен обслуживаться только конечной точкой в вашей модели ActiveResource (опять же, если вы используете сторонний API, вы можете иметь другого выбора нет, но я никогда не получал ARes для взаимодействия со сторонними API).
Мы столкнулись с множеством других проблем ActiveResource, когда он выполняет бессмысленное динамическое создание имен классов на основе вложенных ресурсов с вашей конечной точки, но половину времени делает это неправильно ... Это действительно просто беспорядок.
Мораль истории: гораздо больше поклонника HTTParty сейчас. Эта конечная точка, вероятно, просто не возвращает данные в правильном формате, и если это не так, ActiveResource станет хакфестом, чтобы заставить его правильно читать.