This module will STOP WORKING on June 1 2014 unless we update to REST version of the CCU API

A new and improved REST API is now available to purge content off the Platform.

Existing users must migrate to the new API by June 1, 2014.

If you are currently using the SOAP based API for purge, or if you intend to start using API to purge your content, please read on.

The benefits of the new API are:

• A REST based API vs. the existing SOAP one
• The ability to check the status of submitted requests (request tracking)
• Purge Queue Querying
• No need to rely on email for notification

What does it mean for me?

1. You can now start using the new REST API and enjoy the above benefits.
2. New users must use the new API immediately.
3. Documentation for implementation is available at https://api.ccu.akamai.com/ccu/v2/docs/index.html
4. If you have questions please open a support ticket in Luna.

Bumping the priority on this, since after June the module will be non-functional without this issue being resolved.

There are a few issues with the patch from comment 5, one conceptual (the first one below) and a couple related to execution of the patch.

• The patch adds fields for Rest API settings but does not remove the SOAP fields. Since SOAP is being sunset by Akamai, it seems to me that the option to use SOAP should just be removed entirely from this module.
• The patch is based on 7.x-1.3 release rather than dev and so removes code added in the interim.
  

  169 +
  170 +; Information added by drupal.org packaging script on 2011-12-21
  171 +version = "7.x-1.3"
  172 +core = "7.x"
  173 +project = "akamai"
  174 +datestamp = "1324493436"
  175 +
  

  Lines removed because of basing on 1.3

  184 -
  185 -  // It is possible to have no paths at this point if other modules have
  186 -  // altered the paths
  187 -  if (empty($paths)) {
  188 -    watchdog('akamai', 'No resultant paths to clear for %paths', array('%paths' => implode(', ', $paths_in)), WATCHDOG_NOTICE);
  189 -    return FALSE;
  190 -  }
  191 -
  

• The patch introduces whitespace errors.

  $git apply akamai-restapi-000-D7.patch
  akamai-restapi-000-D7.patch:48: trailing whitespace.
     drupal_set_message($message);
  akamai-restapi-000-D7.patch:126: trailing whitespace.
  $ch = curl_init("$restapi");
  akamai-restapi-000-D7.patch:136: trailing whitespace.
      'Content-Length: ' . strlen($data_string))
  akamai-restapi-000-D7.patch:137: trailing whitespace.
  )
  akamai-restapi-000-D7.patch:175: new blank line at EOF.
  +
  warning: 5 lines add whitespace errors.
  

• Adds commented-out code.
  

  akamai.class.inc
  121 //$data = array("type" => "arl", "action" => "$action", "domain" => "$domain", "objects" => array ("$uris[0]"));
  

• Code is not properly formatted/indented.
  

  * akamai.class.inc
  154 }
  155 }
  156 }
  157 }
  

The above not withstanding, thank you roshan_shetty for taking a first cut at this. It's very much appreciated.

I've taken roshan_shetty's work and made some improvements, including those suggested by Barrett. This work also pulls in issue # 2183829.

I've tested locally, against my Akamai account, but I welcome improvements, as well as suggestions for making this more drupal-y.

Damn. CherryPi beat me to it.

Cleaned up patch and made some updates.

I've been workign here if someone wants to use git instead of living in patchland
http://git.drupal.org/sandbox/joelcollinsdc/2237671.git

I dont see a reason we need to use curl for this instead of drupal_http_request, I think that is the next thing to work on.

now using drupal_http_request

Great stuff, joelcollinsdc--that was my next step. One thing I did note is that cURL didn't work since the REST URL is https, so I had to add in:

CURLOPT_SSL_VERIFYPEER => false
CURLOPT_SSL_VERIFYHOST => 2,

(I should use TRUE for verifypeer, I think.)

Does drupal_http_request take that into account?

Also, there's no need to leave the SOAP stuff in there.

The patch in comment 11 looks good, though I do get a complaint about a blank line at EOP in the .info file

$ git apply akamai-2134145-use-rest-api-11.patch
akamai-2134145-use-rest-api-11.patch:17: new blank line at EOF.
+
warning: 1 line adds whitespace errors.

That said, I'm currently without an account at Akamai I can test against. Has it been verified to actually work, including handling the settings for Action Type and Domain?

I'm also rethinking my initial opinion about ripping out the SOAP options. If we leave them in for now, a) we'll be able to get this out faster by skipping the work necessary to remove them, and b) those using SOAP will be able to continue using until Akamai actually sunsets the service on their. After June 1, we should definitely remove it, but between now and then I'm thinking it should stay. What do y'all think?

I've tested with our Akamai API., yes

Awesome. @cherrypj, @azinck, can one of you (or anyone else) confirm that @joelcollinsdc's patch in comment 11 works as expected? If we can get independent confirmation, I think we can call this thing RTBC and hopefully get it committed.

One thing that I didnt test (that I should have) is that the SOAP stuff wasn't adversely affected by adding in the REST api stuff. We shoudl make sure that both apis can be used interchangably.

I can confirm that this module works for both SOAP and REST (if I check the Rest API default checkbox).

#11 fixes work well for me. Only thing I would suggest is adding $response_data->progressUri (Also "submissionTime" if you think it makes sense.) to the watchdog since that is the only way to track back the urls. (no email confirmation with Soap ccu.)

Thanks

Hmm... The progressUri is only useful to computers though, right? Its not like you can click on it... It would be cool to have another page that listed the queue of purges, but then you have to keep track of the purgeIds somehow.

Here are the options:

estimatedSeconds
progressUri
purgeId
supportId
httpStatus
detail
pingAfterSeconds

we probably should put in a hook_requirements in there to alert people that they need to switch to REST if they have the SOAP url still configured. There is no way to automatically switch over from SOAP to rest via update hook, right? Or are the URLs always the same for everyone?

The attached patch adds a REQUIREMENT_WARNING message if the akamai_rest_default variable is 0.

I like the progress idea @roshan_shetty raised, but it seems like it should be a separate feature request.

Looks good to me! RTBC?

W00t! Thanks for all your work on this folks!

As near as I can tell, there's no checking if the module cannot reach Akamai when the REST API is enabled.

For the SOAP call, I see this:

catch (Exception $e) {
  watchdog('Akamai', t("Error Clearing Akamai Cache: %msg"), array('%msg' => $e->getMessage()));
  throw $e;
}

This exception is helpful if, for whatever reason, the Akamai service can't be reached. (Say a firewall rule or whatever; Akamai adds new IP address *all* the time.)

I see nothing of the sort for the REST API. Am I missing something?