API and Rails - Best way to go - ruby-on-rails

Question

Currently my application uses the FlickRaw gem to pull data from Flickr. I want to refactor and tidy up parts of it more and remove the FlickRaw dependancy.
So, What I am using now is HttParty and calling the Flickr API methods directly.
I have made a Flickr class and in there I have methods such as self.collection, self.photoset and so on to pull the appropriate stuff.
My concern is that from the locations in my app where I actually need to integrate with Flickr using those methods, I have to call Flickr.collection(id). If Flickr suddenly seized to exist, I would have to go and find all those references to Flickr and alter them. I would prefer to rename my Flickr class to something like PhotoHost and have methods in there which DO call Flickr but as the Flickr specific part is all together, it should be easier to alter in the future if required. Does this sound a sensible way to deal with this? How would you go about it?
Also, would the methods in that class map directly 1:1 with the real API methods or would you sort of make you own methods and build an array of data that you actually want before using it elsewhere in the app or would you just send the flickr response to those other areas and deal with it there? - Actually, after typing that it seems the best way to go would be to write a method called (for example) self.photos_for_album(album_id) and then call the appropriate flickr api methods to build up an array of photos and then have the method return that. I guess that would allow me to write the other code around the app to interact with the photos and if I ever change the photo host from Flickr then as long as the new methods return an array in the same format all should be good.
Sorry, This question has been a bit of a braindump, but I would be very interested in hearing how others would go about this?

Answer 1

What you really want to use is something like a Strategy or Adapter pattern. You should create a FlickrPhotoHost module that implements methods that make sense for your app (not necessarily 1-1 with Flickr's api):
module FlickrPhotoHost
def get_albums
# fetch from flickr
end
def get_photo(album_id)
# fetch from flickr
end
end
And then you should have a PhotoHost class that includes this Flickr adapter:
class PhotoHost
include FlickrPhotoHost
end
And then use it wherever it makes sense in your app.
source = PhotoHost.new
album = source.get_albums.first
photos = source.get_albums(album.id)
# and so on...
When flickr dies, you can replace it with InstagramPhotoHost:
module InstagramPhotoHost
def get_albums
# fetch from instagram
end
def get_photo(album_id)
# fetch from instagram
end
end
And the only part of the rest of your app you'll need to change is PhotoHost:
class PhotoHost
include InstagramPhotoHost
end
This may be a bit of an overkill for just one host, but imagine you wanted to implement Instagram and Flickr at the same time? Let PhotoHost decide on runtime:
class PhotoHost
def initialize type
extend case type
when :instagram then InstagramPhotoHost
when :flickr then FlickrPhotoHost
end
end
end
And on instantiation, you can do this for flickr albums:
PhotoHost.new(:flickr).get_albums
Then BAM, instagram:
PhotoHost.new(:instagram).get_albums

Answer 2

Abstracting to the next level of higher abstraction is often a fine idea. Eg Your app would use PhotoHost rather than Flickr.
The opposing view is to watch out for pre-mature optimization. Eg Does your app have an active need to replace Flickr with an alternative? What else could you be spending your time on that might provide more features/benefits to your app and its users?
Also: think about how your abstract PhotoHost will enable your app to talk with more than one implementation at a time (being able to easily display both Flicker and InstaGram photos).
You also asked about the API methods.
I would be careful about changing methods just for the sport of it. Hopefully some thought went into the Flickr api methods.
But you should certainly change methods to add additional functionality that your app can make use of. Eg if the Flickr api is synchronous, you might want to add a set of asynchronous methods that would enable your end users to multitask (or at least get feedback) while the PhotoHost completes the requested operations.