Ryan's Scraps

No really, I couldn’t think of any better way to title this post, and I apologize for that. However, if you actually clicked on this post from your feed reader, you are definitely a geek, and I like that in you.

So what’s this about? It’s really a tiny little change in RESTful routing, but it negates a lot of material out there, including my own. Whenever you have a custom action route defined in Rails:

map.resources :users, :collection => { :filter => :get }

the resulting route no longer uses a semi-colon (;) to delimit the custom action:

GET /users;filter

and instead will use your standard forward-slash (/):

GET /users/filter

Not a big change at all, but it has big repercussions if you’ve got remote clients accessing these URIs already. (And we all do now-a-days, right?).

tags: ruby, rubyonrails, REST

Everybody knows that here in the South all we do is sit on the porch in our rocking chairs, chew, and have hoedowns, right? In that spirit Ruby aficionados across the south now have their own such festivity – The 2007 Ruby Hoedown in Raleigh, NC from August 10th – 11th. SIgn up to be notified of further details…

tags: ruby, rubyhoedown

The days of natively supported object transactions are gone. Object transactions you say? Yeah, that nifty little trick that performs rollbacks not only of the database state, but of the object state as well:

1
2
3
4

Account.transaction(from, to) do
  from.withdraw(100)
  to.deposit(100)
end

If there was a failure within the transaction block above not only would the database have been rolled back, but the internal state of each object argument (from and to in this case) would have as well.

This was previously deprecated, so if you’re still using it, shame on you. All is not lost, however – you can use bitsweat’s object transaction plugin to get this behavior.

tags: ruby, rubyonrails

With the rise of REST as a legitimate design methodology, and its first-class support in Rails, no longer are the lesser known PUT and DELETE http request methods languishing in obscurity. The awareness of REST has brought them to the forefront, completing the quad-fecta of GET, POST, PUT and DELETE.

But… there’s more. Yes, there are actually eight http request methods defined by the HTTP 1.1 spec. And why don’t we hear much of those other four request methods? Well, they’re of varying levels of usefulness to us as application developers (note that’s ‘varying’, not ‘negligible’). So here is my attempt to bring these ignored requests into the light so you can at least make your own decision as to their usefulness – and make an informed decision rather than one of ignorance.

HEAD

Think of the HEAD request method as a metadata request. You’re asking for the headers of a GET request for the same resource without getting the resource itself. This lets you see things like the size of the resource being requested, the last-modified date of the resource and any other request headers associated with the resource without actually incurring the overhead of sending the resource across the wire.

As an example, the Amazon S3 service uses a HEAD request to view information about a stored object like its size and permissions without getting the whole object. As these S3 objects represent files you can see how valuable HEAD is as you wouldn’t want to download a 1Gb file just to see the properties of that file.

OPTIONS

In the absence of human-consumable documentation, it’s tough to know what methods are supported by a particular service. For example, how do I know if I can call HEAD on a resource URI? And even in the presence of complete developer documentation, wouldn’t it be great if you could just point to a root URI and programatically interrogate the service to determine its capabilities? Yeah, that would be great and would really open up a new world of simple but semi-automated REST-based services. This is what OPTIONS attempts to do.

Unfortunately, there’s some ambiguity in the request/response spec of the OPTIONS request method. The spec itself is tight lipped about what a response looks like and even how to properly request the server capabilities. There this page-turning proposal that attempts to clear up these ambiguities, but it’s a bit outdated and I don’t know if was accepted or rejected.

This seems to be a particularly useful and important request method, I’d love to dig a little deeper into this to see how it’s being used out there in the wild. If you have any such pointers, please post them here.

TRACE

TRACE appears to be very similar to your traceroute unix command. It is “used to invoke a remote, application-layer loop back of the request message”. And how is the traveled path conveyed back to the sender? Well, the response will have a Via header value that will contain each node along the path. So instead of seeing a printout on your command line like traceroute, you can just dump the Via header contents which will look something like this (where ricky, mertz etc… are machine names):

Via: 1.0 ricky, 1.1 mertz, 1.0 lucy

It’s important to note this is not identical to traceroute in that it won’t show you the hops along the IP route, it just shows you what happens within the remote service routing.

CONNECT

CONNECT is apparently a way to request that web proxies dynamically switch to a secure IP-based connection, like an SSL tunnel. This seems particularly out of place as it operates more on the protocol level and not really on the underlying resource (as does TRACE to a certain extent). Hey, I didn’t write the thing.

Interesting huh? Yeah, didn’t think so – but it’s important to see the full picture of http and not just what web browsers or your particular application framework expose… and now you have that luxury.

tags: REST, http request methods

See here from some syntactical changes that occurred after this post was published

I gave a little chat last night at the Central Virginia Ruby Enthusiast’s Group – otherwise known as the Richmond Ruby Brigade – about REST, ActiveResource and how to build client services from the marriage of the two.

It was a really good group and I’d encourage anybody in the central virginia area to go check them out if they get the chance. It sounds like they’ve got some good speakers lined up in the next few meetings to make it worth your while (and they had free pizza last night – what a grade-A operation!)

For those that are interested, here’s the PDF version of my presentation. As you can imagine much of the value is lost without having the dialogue to accompany the presentation, but I think it somewhat stands on its own. Most of the examples are drawn from my ongoing work on ContactsAPI – a site meant to further the adoption and education of ActiveResource and REST in general. Check it out if you have the time, but again, it’s a work in progress.

tags: ruby, rubyonrails, cvreg

If this had you running for the hills it appears that there’s now a better ruby-based option for continuous integration with your Rails project: CruiseControl.rb. (And it’s not just for Ruby/Rails projects either…)

Give it a go, eh?

tags: rubyonrails, rails, continuous integration

I recently got a new car loan from Capital One and upon logging into my online account console I saw that the loan was titled ‘Google Auto Loan’:

I did not get to the Capital One site through an adwords ad nor did I through a Google search.

Does anybody have any insight on this – is Google experimenting with the consumer loan business? It’s an interesting bit of speculation. I could see it going down like this:

1. Google partners with a traditional financing company (i.e. Capital One).
2. Whenever a traditional new loan application comes into the financing company, Google does a parallel query against what Google knows of the person (using their name, email address etc…). Google knows my search history, knows that I have a GMail account (since that’s the email address I gave to Capital One), knows a lot of my daily habits (as I use Google Reader for my feeds). This information probably paints a pretty good picture of what kind of person I am and, as a result, what kind of credit risk I am.
3. The combined methods of Google and Capital One are able to drill much deeper into my suitability for a competitive loan than straight conventional methods. Combined with the fact that my loan type specifies automatic withdrawals from my bank account (which further reduces my account overhead) I am offered a great loan rate while Google (almost acting as a co-signer) shares the investment risk with Capital One and takes part in the loan profits.

Ludicrous?

tags: google, loans, capital one