December 07, 2008

Posted by John

Tagged gems, httparty, and web services

Older: Watch John Speak, Drink John Drink

Newer: Using Gmail to Send Email With Rails

HTTParty Divorces ActiveSupport

Right off the bat I would like to say that the divorce was completely amicable. I love ActiveSupport and use it with almost every project, even when haters complain. Originally, HTTParty’s parsing of JSON and XML just used ActiveSupport’s built in mechanisms and it worked great.

A few people brought up issues with ActiveSupport and I rolled my eyes. Then, once the roll was complete I thought about it and decided if I could use the JSON gem and find something comparable to ActiveSupport’s Hash#from_xml, I would be ok with removing it. I did some research and stumbled across extlib’s Hash#from_xml and liked it, so I ganked to power the XML de-serialization in HTTParty 0.2.0.

I removed ActiveSupport as a dependency and added the JSON gem. I then added a few core extensions, swapped out the de-serialization and HTTParty was free to date again.

But Wait, There Is More

So that update alone would probably be worth a blog post, but it is not the only thing that has changed since I first posted about HTTParty. Since it was suggested, I’m going to show a few of the updates here as well.

Proxy Support

Thanks to francxk, you can now use proxies.

class MyProxyParty
  include HTTParty
  http_proxy 'proxyaddress.com', 80
end

Using the http_proxy method, you can set the address and the port of the proxy you would like to use. I’ve never needed a proxy personally but I think this was a worth addition.

Format Detection Based on Content Type

When HTTParty was released, you had to declare a format if you wanted the response to be parsed in some way. For example, the old way of parsing the Twitter public timeline was the following:

class Twitter
  include HTTParty
  </code><strong><code class="ruby">format :json</code></strong><code class="ruby">
end

Twitter.get('http://twitter.com/statuses/public_timeline.json')

With the response content type detection, the new way is one less line of code and one less thing to remember.

class Twitter
  include HTTParty
end

Twitter.get('http://twitter.com/statuses/public_timeline.json')

Much thanks to Jay Pignata for adding this initially.

Automatically Follow Redirects

Alex Vollmer snuck into HTTParty like a thief in the night and added automatic following of redirects. With his addition HTTParty automatically follows up to 5 redirects, after which it will raise an HTTParty::RedirectionTooDeep exception. Feel free to bump up or down the redirect limit like this:

class RedirectFollower
  include HTTParty
  base_uri 'http://someurlthatredirects.com'
end

RedirectFollower.get('/foo', :limit => 2)

HTML format

A few people mentioned that they would like a way to not automatically parse the response based on the content type. The simple fix for that was allowing an html format and making sure that format can optionally be passed in with an request.

class Twitter
  include HTTParty
end

puts Twitter.get('http://twitter.com/statuses/public_timeline.json', :format => :html)

Even though the request above returns the JSON content type, it will not be parsed as JSON, but instead will just return the JSON as plain text/html.

HTTParty.get/post/put/delete

One of my favorite additions was by Eli Miller, just a few days ago. We were chatting and he mentioned how he liked using HTTParty as a simple net/http wrapper. A few minutes later he sent me a pull request with a nifty addition that allows using HTTParty as a sane wrapper around net/http, without even making a new class and including HTTParty. You can now turn the Twitter public timeline into a ruby hash in one line thanks to Eli’s addition:

HTTParty.get('http://twitter.com/statuses/public_timeline.json')

Yep, that is it. It will fetch the response, detect that it is JSON and use JSON.parse to turn the response into a Ruby hash. It really doesn’t get any easier.

Conclusion

Ok, so now all you hold outs who haven’t used HTTParty yet have absolutely no reason. Use it with Rails, Merb, Sinatra or whatever the heck other framework you use, with no worries about including all of ActiveSupport.

11 Comments

  1. HTTParty is The Truth. Thanks very much to everyone that has been working on it. I’m using it for a couple of projects that hook into different external APIs, and it’s lovely to have one library that works with so many services. Thank you!

  2. malkomalko malkomalko

    Dec 07, 2008

    I think since you took out activesupport requirement, there are some to_xml_attributes undefined method errors occurring on Hash, when trying to use the .get method.

  3. @maklomaklo Ok. I’ll look into it. Can you provide me with the xml causing issues? That would help.

  4. John

    http://gist.github.com/33647 is a stack trace of what happens when using ActiveRecource where httparty-0.2.0 is used. The XML is just standard Rails render :xml => @object stuff.

    HTH

  5. > A few people brought up issues with ActiveSupport and I rolled my eyes.

    Just requiring AS in JRuby takes about three seconds on my box. Normally I dig ActiveRecord, but if it’s going to behave like that, it’s an insta-fail for any JRuby-targeting projects in my eyes.

  6. @Kenneth – Yeah the problem is the core extensions I included conflicting with active support which active resource requires, I’m sure. I’ll be fixing it before too long.

  7. @malkomalko – You were correct. I was missing a method. 0.2.2 fixes this. Also, 0.2.1 fixed the issue of HTTParty conflicting with ActiveSupport (and thus ActiveResource).

  8. malkomalko malkomalko

    Dec 09, 2008

    Sorry I didn’t provide more info up front :)

  9. I am glad you did this. ActiveSupports Hash.from_xml has proven to be buggy for me, especially when I was working with the Flickr API. It would wipe out attributes/values if they had the same name (Flickr’s API for tags as an example)

    This is great. Using it in a project now and love it.

  10. Hi John,

    I looove HTTParty and have been using it a lot. One quick, probably naiive question, are multiple base_uri’s threadsafe since they are set as so:

    self.class.base_uri=“http://www.example.com”

    ? I need to switch base_uris between several different urls.

    Thanks,

    John

  11. @John – No it is not threadsafe. I don’t really use base_uri anymore. I typically just set an instance variable equal to the base uri and pass that around.

Sorry, comments are closed for this article to ease the burden of pruning spam.

About

Authored by John Nunemaker (Noo-neh-maker), a web developer and programmer who has fallen deeply in love with Ruby. More about John.

Syndication

Feed IconRailsTips Articles - An assortment of howto's and thoughts on Ruby and Rails.

Feed IconRails Quick Tips - Ruby and Rails related links.