Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question

3 Answers 3

up vote 2 down vote accepted

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.

share|improve this answer
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 Oct 31 '12 at 2:30
Whoops. I guess I misunderstood. :) Sorry about that. –  Ben Oct 31 '12 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.

share|improve this answer
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? –  jschoen Oct 31 '12 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 Oct 31 '12 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. –  jschoen Oct 31 '12 at 3:43

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)

share|improve this answer
Is it a standard practice? Is there a name to this pattern? –  Amol Oct 31 '12 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 Oct 31 '12 at 18:27

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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