I wouldn't worry too much about having a "messy" models folder. If you had 50 models, it might be a concern, but you don't currently have many and it's easy to move things around later.
What is the purpose of ReviewSite? It seems like an unnecessary model.
has_many :facebook_pages, through: :locations
has_many :google_pages, through: :locations
has_many :yelp_pages, through: :locations
belongs_to :customer (or something)
belongs_to :business (if you want to attach it to a business, could also be location)
As you can see here, the concept of a "page" seems repeated so you may still want to consider how truly separate they are.
- site ("google", "facebook", "yelp")
- extra_data (json column, can be fully unique to each site)
Then you could just write other Ruby classes for handling the unique API situations. For example, to get the correct API client, you'd do something like:
This would be a more generic way of approaching things. You can have a json column to store any data that's unique to each business instead of making separate models for each.
Personally I would probably take this approach with generic pages. I haven't seen anything that seems to prevent taking this approach. This is how I handle the different APIs for Hatchbox.io btw. Servers on Hatchbox are like Pages and Reviews in your app. Sure they may be on a different service, but I can still store the generic information I care about in a single table and just keep track of which service it is. Then I write Ruby classes to handle the specifics and store the data on the model. Unless the data is vastly different, you will probably be best off with the generic Page like I'm doing with Servers. You can have a json column to store your extra information that may be unique to each site. If there is a lot of unique information for each Page, then definitely split up the models.