StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p><code>ActiveResource</code> is going to expect that endpoint to return the data in a very specific format.</p> <p>For the longest time we've been using ActiveResource at my company for inter-application communication. However more recently we've started leaning towards HTTParty because it performs a lot less voodoo magic, and tends to be a much small exercise in hair-pulling.</p> <p>Here's an example of how we're using HTTParty now:</p> <pre><code>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 </code></pre> <p>The problem with ActiveResource is that it will take the very specifically-crafted json or xml markup, and instantiate ActiveResource objects and nested objects based on it. It's having issues calling <code>collect</code> because something in the json response was supposed to be formatted like an enumerable, and wasn't (likely the parent node should have been an array or something, not sure), which makes it blow up.</p> <p>With HTTParty you get a json-parsed collection to work with.</p> <p>It's easy enough for me to do this:</p> <pre><code>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" # }] </code></pre> <p>Which let's me access jobs via an easy collection array/hash construct <code>jobs[0].fetch("description")</code>, as opposed to ActiveResource: <code>jobs[0].description</code>. ActiveResource is slower to insantiate those collections, needlessly takes up memory with them, and encourages you to duplicate code that should just be served by the endpoint in your ActiveResource model (Then again, if you're using a third-party API you may have no other choice, but I have never successfully gotten ARes to interface with third-party API's).</p> <p>We've run into a lot of other ActiveResource problems where it does this nonsensical dynamic creation of class names based on nested resources from your endpoint, but half the time does it incorrectly... It's really just a mess.</p> <p>Moral of the story: Much more of a fan of HTTParty now. That endpoint is probably just not returning data in the right format, and unless it does ActiveResource will be a hackfest to get it to read it right.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload