For expanded service definitions (e.g. those using an array instead of just a string) it should be possible to designate that said service requires an API key and have a field automatically be created for it on the API Keys settings page. Note that there are several components here:

  • A setting for the key has to be made available
  • The variable holding the setting has to be deleted when the module is uninstalled
  • The variable has to be used in the callback URL definition

That last point is a little complicated, because some services allow you to use them both with and without API keys, so we might need the ability to specify two callback URLs -- one if the keys are available and one if they're not. Also, some services (like bit.ly) need multiple keys.

Comments

icecreamyou’s picture

icecreamyou commented

Proposed structure:

  return array(
    'Service name' => array(
      // ...
      'variables' => array(
        'machine_name' => t('My Service API Key'),
      ),
      'url' => http://example.com/endpoint/?url=, // optional; if not given, this service won't be visible unless the keys are filled out
      'key url' => http://example.com/endpoint/?key=[machine_name]&url=,
    ),
  );

This will require reworking _shorten_get_url().

nagarajugoli’s picture

nagarajugoli commented

i need service (drupal 7) with api key. i am connecting my own network with api key and json-rpc.

icecreamyou’s picture

icecreamyou commented

@nagarajugoli: This issue is about an API change that will allow modules to expose new generic services that require keys without doing a little extra work of tracking the keys themselves. If you are using your own network with your own key, you can just include your key directly in the URL you are providing as the endpoint, and everything should work without the change proposed above.

nagarajugoli’s picture

nagarajugoli commented

ok, i tried with json-clinet , any way thanks.

icecreamyou’s picture

icecreamyou commented
Issue summary: View changes
Status: Active » Closed (won't fix)

Closing because I'm unlikely to work on this and it's a moderate amount of effort and code on the module's side in order to relieve maximum a few lines of code (often zero) on the user's side