Announcement Announcement Module
No announcement yet.
1.1.X Naming Conventions for appId/appSecret? Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • 1.1.X Naming Conventions for appId/appSecret?


    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:

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

    Facebook - appId, appSecret
    FacebookConnectionFactory - appId, appSecret
    FacebookServiceProvider - appId, appSecret

    LinkedIn - 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?

  • #2
    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?


    • #3
      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 hasn't bubbled up as a high priority and that's why I've not bothered changing them.