I am currently creating a library that is a wrapper for an online API. The obvious end goal is to make it as easy for others to use as possible. As such I am trying to determine the best approach when it comes to common parameters for the API.

In my current situation there are 3 (consumer key, consumer secret, and and authorization token). They are essentially needed in every API call. My question is should I make these 3 parameters required for each method or is there a better way.

I see my current options as being:

  1. Place the parameters in each method call

    public ApiObject callMethod(String consumerKey, String consumerSecret, String token, ...)

    This one seems reasonable, but seems awfully repetitive to me.

  2. Create a singleton class that the user must initialize before calling any api methods. This seems wrong, and would essentially limit them to accessing one account at a time via the API (which may be reasonable, I dunno).

  3. Make them place them in a properties file in their project. That way I can load the properties that way and store them. This seems similar to the singleton to me, but they would not have to explicitly call something to initialize these values.

Is there another option I am not seeing, or a more common practice in this situation that I should be following?

4 Answers 4


I think what Telastyn is suggesting is

public class ConsumerContext { string key; string secret; string token; }
public ApiObject callMethod(ConsumerContext, ...)

This is sometimes a way of providing locale information as well - add it to the context.

  • That is not what I am suggesting, but can be a fine option if your API is large or the tokens used in a variety of diverse locations.
    – Telastyn
    Commented Oct 31, 2012 at 2:30
  • Whoops. I guess I misunderstood. :) Sorry about that.
    – Ben
    Commented Oct 31, 2012 at 12:55

None of the above!

As part of the API have a context or connection or whatever is most appropriate. Have the consumer specify these tokens on constructing, then the method calls are instance methods on the context.

  • I am not sure I follow. Are you essentially saying create a class they initialize with the needed params, and they pass that to each api method I create. Kind of like passing in a JDBC connection to method? Commented Oct 31, 2012 at 1:49
  • @jschoen - no, I'm saying that you create a class they initialize with the needed params and then the API methods (on the created object) just access them as member variables since they live in your connection context.
    – Telastyn
    Commented Oct 31, 2012 at 2:19
  • Ok, I see what you are saying. The only issue I see with this, is that I would end up with a huge class. I would prefer to break it up into logical groups, but they need to all share this same information. Commented Oct 31, 2012 at 3:43
  • You can still split it up into separate classes, just have the 'context' object act as a factory, and the created objects have a reference to the parent context.
    – Bwmat
    Commented Jun 27, 2015 at 5:44
  • @bwmat - you could, but then your context knows about every api call and needs to be modified whenever unrelated API things are changed.
    – Telastyn
    Commented Jun 27, 2015 at 13:25

This is merely to demonstrate with formatting what I think Telastyn was describing...

public class ConsumerContext 
  prop string key
  prop string secret
  prop string token

  # default ctor
  public ConsumerContext(){}

  # parameterized ctor
  public ConsumerContext(string key, string secret, string token)
     this.key = key
     this.secret = secret
     this.token = token

  public void FooWrapper(fooApiSpecificParamList)
     api.foo(this.key, this.secret, this.token, fooApiSpecificParamList)

  public void BarWrapper(barApiSpecificParamList)
     api.bar(this.key, this.secret, this.token, barApiSpecificParamList)

  • Is it a standard practice? Is there a name to this pattern?
    – Amol
    Commented Oct 31, 2012 at 10:55
  • Is it standard practice to simplify interfaces and encapsulate data when appropriate? Sure. Private Class Data and Facade are the patterns that this example might most resemble. Ommitted from the example is the act of composing the three security related fields into a single security context object, and passing that single object to the ConsumerContext which would be even more ideal, somewhat like Ben suggested, but is an exercise left for the implementor.
    – JustinC
    Commented Oct 31, 2012 at 18:27

I can see two ways:

  • coalesce all your parameters into a single context object, at the API client side. Each time you call your API, pass the context object as parameter.
  • use a similar context object, but store it at the API side. Give the client a token that identifies the context object and ask the API client to pass it each time it calls the API. This is useful if you cannot easily send objects to the API (e.g. HTTP API)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.