I’ve given over maintenance of RestClient to Julien Kirch (archiloque). He's got a 1.1 release now in Gemcutter/Rubyforge, with some hot new features:

With HTTP basic auth starting to get the cold shoulder (passwords are basically low-complexity symmetric keys, not too hot for truly secure authentication), and OAuth experiencing growing pains, what options are available today for truly secure RESTful authentication?

Cyril Rohr gives us Cacheability, a caching HTTP client which cleverly mashes together RestClient and Rack::Cache. It can cache results in memory, on the filesystem, or in memcached. Grab a copy:

Peter Wiliams suggests versioning REST APIs with the Accept header. I agree that putting the version in the URI (e.g. GET /api/v1/resource) is ugly - for the Heroku client I used a custom header (X-Heroku-API-Version), which seems preferrable to me because you don’t pollute your mimetypes.

New stuff:

• Access response headers:

RestClient.get('http://example.com/pic.jpg').headers[:content_type]

• Configurable timeout, contributed by Marc-André Cournoyer:

resource = RestClient::Resource.new 'https://example.com', :timeout => 20

• require ‘restclient’ is now the preferred notation, though require ‘rest_client’ will continue to be supported indefinitely.

Restclient 0.8 released with new features:

• The restclient binary can take get/put/post/delete as the first argument:

A few more chances for you to catch me in person:

• Silicon Valley Ruby on Rails Meetup, Sept 25 @ 7pm (this Thursday). My presentation is titled: Instant Rails Deployment to Heroku with Git. Heroku’s API and Git integration is our secret weapon, so I’m pleased to be giving a talk focused entirely on these tools.
• RubyConf 08, Nov 7 @ 1:15pm. Blake Mizerany and I will be presenting Lightweight Web Services with Sinatra and RestClient. Besides shamelessly pimping our respective open source projects, we’ll talk about why we think the future is all about small apps loosely coupled into a larger system.

I keep thinking I’ll run out of things to add to RestClient, but then I keep wanting more features. So here comes 0.7, with gzip/deflate support and client-side logs.

I like models. They do the heavy lifting. They’re easy to spec. You can grab them at the console or from script/runner with ease.

John Nunemaker created HTTParty, a library for making web requests. So the options for making web calls from Ruby are now:

RestClient 0.6 includes an interactive shell contributed by Blake Mizerany. Lay down your curl, for we now have a Ruby Way to fetch resources at the command line!

I’ve always liked to build systems with a bunch of small apps that talk to each other through various protocols. Orion and I built TrustCommerce in this manner, and that gave it some pretty impressive fault-tolerance and scalability.

gem install rest-client for new features:

• SSL support
• User/password embedded in the url (e.g. https://joe:mypass@example.com)
• Subresource nesting with syntax (e.g. site['posts/1/comments'].get) (more examples)
• Better exception classes with access to the response object and more readable output in irb

While we wait for web broswers to become fully REST-capable, Poster is a handy Firefox plugin for sending any type of HTTP request, including all four verbs and different content types. I usually use rest-client at a rush shell for one-offs; but if you need your browser’s cookies for a call that can’t be authenticated with http basic auth, or you just want a dialog that shows all the options visually, Poster is quite handy.

Harry Fuecks thinks MVC might be overrated. In a world of web resources, why not combine models and controllers together? Imagine replacing ActiveRecord (or my new favorite, DataMapper) with a server-side version of ActiveResource. GET, POST, PUT, and DELETE are filled in automatically, and you can extend their functionality and add suport methods.

The fourth release of rest-client includes a patch from Greg Borenstein that makes it easy to send form-urlencoded data by passing a hash instead of a string as the payload:

When serving up an ActiveRecord as resource, you can use options like :only and :except to to_xml. But in most cases, you want the same fields served every time - on create, update, and get. So put the options into the class itself:

REST appealed to me right from the get-go. But it’s taken me a surprisingly long time to wrap my head around all of its implications. Some of my recent projects - building the fully RESTful Heroku API, working with Mike Clark on the Nested Resources recipe for his upcoming book, and writing rest-client - have allowed me to finally get a handle on how all the pricinples of REST fit together into a unified whole.

Based on Dan Kubb's suggestion, I’ve implemented an ActiveResource-style accessor for rest-client. This also supports basic auth, so now:

REST is part of the Ruby Way. Which is why I’m surprised that every time I go to access a RESTful resource, I find myself writing some sort of ad-hoc rest client. Net::HTTP is too low level - you’ve got to write at least three or four fairly dense lines of code even for a relatively simple GET or PUT.