just a dude abiding

Using httpriot on IOS

One of the things that surprised me when I first started with iPhone development is the verbosity of the built-in classes for making HTTP requests. (see: Using NSURLConnection ) So I quickly started looking for a wrapper library that simplifies this process. I found two candidates ASIHTTPRequest and httpriot. For no reason other than some familiarity with the Ruby library that inspired it, I chose httpriot.

It turned out to require a BIT more code than I had expected, so I’ve documented my setup, and hopefully some of my reasoning here. I’m probably wrong in some of this, but there’s no easier way to know than to share it with the world.

After making a few requests, I noticed some repeated code which seemed ripe for abstraction. I started my abstraction by create a simple subclass of httpriot’s main class, HRRestModel, named RestRequest. From what I gathered, this is the recommended way of using httpriot to begin with.

What this allows me to do is specify some basic authorization parameters that I want to use for most every request. The other thing I found is that my actual View Controllers didn’t end up needing to use all of the different failure and success cases that the HRResponseDelegate provides. So I went ahead and created my own delegate protocol, RestRequestDelegate. This protocol requires only two methods one for success, and one for failure.

This is the class that shows the real duplication of effort required to use httpriot. Notice that we have to implement five different methods to handle all of the success/failure cases. Using this subclass method, we only have to implement two per request.

Some notes on the actual implementation of the RestRequest: You’ll want to set your own BaseURL. You can do this per request class, or as I do here, in the main base class. At a glance right now, the processResult and processFailure methods may seem superfluous, and as of right now, they are. But their purpose is that they can be overridden in subclasses to be used in any data processing or reorganization. Also note that I go ahead and enable/disable the network activity indicator in this base class. I made the decision that I wanted the indicator to show for all HTTP requests, so I just went ahead and handled it here.

Now on to a sample class that subclasses our new, simpler, RestRequest class. There’s not really much to explain here, so I’ll skip on down to the implementation class.

The fetch method just takes in an object (which is our view controller in this case), and then calls the correct URL. It could also take in any HTTP parameters you need to pass, but for this example I’m not using any.

We then have a simple processResult and processFailure. Again, this is a simple example, so we don’t have any data processing to do, so we just call the delegate method, restRequestSuccess and pass it our result. Simple as can be.

Now here is where we can finally see the real fruits of our labor. All of those subclasses, and delegates, and protocols, for…this. Simple, clean View controller code. Note that we call the fetch method of the GetWhateverRequest class, and pass in self as the acting delegate.

In our success method we take the results, look up a specific value based on a key, and set it into a label. On failure we’d probably want to show an alert or something.

By this point you’re probably thinking that this is a lot of work for a single http request, and you’re right. Where I found this set of abstractions to make sense is when you have a handful of requests, that may be called from several View Controllers, so it make sense to push as much of the setup as possible into the request subclasses. Obviously if your app has a different usage patter, this may not apply. Either way, using this particular set of abstractions my View Controllers are almost entirely free of boiler-plate code and my requests are highly re-usable and portable.

Hopefully this serves as a nice, albeit brief, tutorial into httpriot.