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?

| improve this question | | | | |

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.

| 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.

| 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? – Jacob Schoen 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. – Jacob Schoen Oct 31 '12 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 Jun 27 '15 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 Jun 27 '15 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)

| 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

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)
| improve this answer | | | | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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