1.1.X Naming Conventions for appId/appSecret?

[gemini929]

Craig,

I know the 1.1.x API is still in flux. As a result, there are some naming inconsistencies with the appId/appSecret that I'd like to get your take on so that I can better align my API with the direction you are taking. For example:

Twitter
EnableTwitter - appId, appSecret
TwitterConnectionFactory - consumerKey, consumerSecret
TwitterServiceProvider - consumerKey, consumerSecret


Facebook
EnableFacebook.java - appId, appSecret
FacebookConnectionFactory - appId, appSecret
FacebookServiceProvider - appId, appSecret


LinkedIn
EnableLinkedIn.java - appId, appSecret
LinkedInConnectionFactory - consumerKey, consumerSecret
LinkedInServiceProvider - accessToken, secret


OAuth2Template - clientId, clientSecret

Based on the Facebook API, it looks like you are moving to use appId/appSecret. Is this where you are going?

[gemini929]

Thinking about this more, if client_id and client_secret are used in the URL for OAuth, would it make more sense to align with clientId and clientSecret?

[habuma]

This exact thing bugs the crap out of me and has since Spring Social began. Do I sync up with what the OAuth specs call it (and they differ between specs)? Do I sync up with what each individual provider calls it? Do I pick one and use it across the board no matter what the provider or any specific version of the spec says? I don't know.

At one time, I settled on calling it whatever the provider called it. But then the providers started changing their minds (Facebook, especially). Now I'm inclined to sync up with the OAuth specs, which are less likely to change. Even so, the names will be different between OAuth 1 and OAuth 2.

Even so, and even though this has bugged me...it hasn't bubbled up as a high priority and that's why I've not bothered changing them.