Can Her support the concept of scoped API objects? about her HOT 10 CLOSED

Ran into a similar problem when we wanted to use the same model with two different endpoints (depending on a user selection). Did some nasty things with class unloading to make this work. It would be nice to have an official solution.

from her.

Did some nasty things with class unloading to make this work.

Can you share this particular solution? I just want to be sure of what you’re talking about.

from her.

I have something like this in my Rails controller:

before_filter :initialize_foo_models

# ...

# FooPlugin.setup does the Her::API.new and .setup(...) things
def initialize_foo_models
  if foo?
    FooPlugin.setup configs[:foo]
    reload_foo_model_classes
  elsif bar?
    FooPlugin.setup configs[:bar]
    reload_foo_model_classes
  end
end

def reload_foo_model_classes
  foo_lib_path = Gem::Specification.find_by_name('foo_plugin').gem_dir + '/lib/foo_plugin'
  [:User, :Address].each do |class_name|
    if FooPlugin.const_defined?(class_name)
      FooPlugin.send(:remove_const, class_name)
      load "#{foo_lib_path}/#{class_name.downcase}.rb"
    end
  end
end

from her.

I’m gonna close this issue now for lack of activity. If you guys want to submit a pull request for this feature, you’re more than welcome!

from her.

I'm in the need of something like this now. I would like to be able to do:

admin_api = Her::API.new do |c|
  c.use FaradayMiddleware::OAuth2, @admin_token
end

user_api = Her::API.new do |c|
  c.use FaradayMiddleware::OAuth2, @user_token
end

User.scoped_api(admin_api).all.first  # uses the admin token
User.scoped_api(user_api).all.first  # uses the user token

# it should also support relationships:
User.scoped_api(user_api).find(1).profiles.first  # /profiles should be retrieved using the scoped api

I've been trying to make this change in Her but apparently this might require a major refactor that separates the models from the apis. Are there any plans to add this feature?

from her.

Another option might be to introduce the idea of a Connection, untying the Faraday options from the Api object. A Connection could then be specified on the same way as my previous comment. Note that this will require an important refactor as well.

from her.

As a workaround you could use the newly introduced Proc support of use_api (#166)

from her.

@pencil thanks! That helps, although the app I'm dealing with makes the two types of requests (admin and current user) and I can't find a way to send that information down to the proc :\

from her.

@alfonsocora You would want to have some kind of class attribute on the model or a global variable. In your Proc you would check this to decide what API to use. It's an ugly workaround, but it could work 😁

from her.

That's almost the precise example for using a proc - the need to
dynamically choose an API for use_api.
On Aug 17, 2013 2:28 AM, "Nils Caspar" [email protected] wrote:

@alfonsocora https://github.com/alfonsocora You would want to have some
kind of class attribute on the model or a global variable. In your Proc you
would check this to decide what API to use. It's an ugly workaround, but it
could work [image: 😁]

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/25#issuecomment-22808610
.

from her.