While it's OK to request subscription info every time when starting out, eventually you'll need to cache it.
Subscription info is all returned in a single response, so you can just cache the results of that response, either raw, or split it out into the details you care about. It is suggested that you keep the cached info together, since that will make it easier to invalidate…
For cache invalidation, your application should provide a url to Spreedly in your site settings, for example:
http://meresheep.com/customers-changed
When any of your subscribers change, Spreedly will POST a comma separated list of subscriber id's (your customer id's) to this url.
At that point, you can either retrieve the new information for those subscribers immediately, or just expire your cache and let your caching mechanism fill it in if it's requested again. The post will have a parameter named subscriber_ids.
Spreedly even notifies you when a subscriber expires.
What if your website is down when Spreedly tries to notify you? That's ok. We'll try again a minute later. If you're still down, we'll try again 2 minutes later. Each time you're down, we'll double the amount of time we wait to attempt notification again. Once you successfully receive the message, we'll go back to notifying you right away in the future. We'll know you received the message if you respond with a 200 (OK) response code.
So how do you setup your site to hear this POST? Well, in Rails it's pretty easy. First, you need a route. Something like this:
map.subscribers_changed '/subscribers_changed', :controller => 'users', :action => 'changed_on_spreedly', :conditions => { :method => :post }
Or it might look like this:
map.resources :users, :collection => { :changed_on_spreedly => :post }
Then you can create a method in your UsersController (or wherever you've got your route pointing). It could look something like this:
class UsersController < ApplicationController
skip_before_filter :verify_authenticity_token, :only => :changed_on_spreedly
def changed_on_spreedly
subscriber_ids = params[:subscriber_ids].split(",")
subscriber_ids.each do | each |
user = User.find_by_id(each)
user.refresh_from_spreedly if user
end
head(:ok)
end
end
A 200(OK) response will be returned by such a method.
Let's say you've setup your subscribers changed url to look like this:
http://meresheep.com/customers/changed
You can easily test that you're responding to this locally on your development box by using curl. For the example below, the application is running on port 3000:
curl -v --data-ascii subscriber_ids=22,5,7 http://localhost:3000/users/changed_on_spreedly
This curl command simulates what Spreedly will be sending you. In the example, 3 subscribers had changed. Their id's were 22, 5, and 7.
Return to the Integration Guide ↑
If you've enabled forgery protection (protect_from_forgery) in your Rails app, you need to tell Rails to skip verification on whatever action Spreedly is calling, since it's doing a POST and not a GET. A POST would normally require the authentication token to be present, which Spreedly isn't providing.
Forgery protection can be skipped for a specific action by adding this to your controller:
skip_before_filter :verify_authenticity_token, :only => :changed
Where “:changed” is the callback action for Spreedly.