The Rackspace Cloud Files service is offered with a RESTful API interface which is useful for integrating into existing applications. At times, it can be used for directly interacting with the API to perform ad-hoc tasks or to troubleshoot Cloud Files itself - a very useful tool for doing this from the command line is cURL, which is a generic client supporting several protocols including HTTP. Let's take a look below: cURL Installation

• Curl Installation

 cURL Basics

• Performing an HTTP Get
• Performing an HTTP POST
• Performing an HTTP PUT
• Viewing the HTTP headers
• Viewing more HTTP debug information
• Sending HTTP headers

 Authenticating with the API

• Authenticating with the API

 Cloud Files cURl Recipes

• Storage recipes
• Listing containers
• Creating a container
• Deleting a Container
• Downloading an object
• Uploading an object
• Deleting an object
• Performing a server side copy
• Updating object headers
• CDN recipes
• Listing CDN enabled containers
• CDN enabling a container
• Viewing a container's CDN details
• Updating a CDN's container attributes 
• Purging an object

  cURL installationBefore using cURL it needs to be installed. All the major distributions have packages for it. The following is an example to get it installed on Debian/Ubuntu: 

$ sudo apt-get install curl

 Similarly, the following command will install curl for Fedora/CentOS/Redhat: 

$ yum install curl

 Once installed, the following command will verify that it is ready to use: 

$ curl --version

curl 7.21.3 (i686-pc-linux-gnu) libcurl/7.21.3 OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.18

Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smtp smtps telnet tftp 

Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz

 cURL may also be installed on Microsoft Windows. This may be done by visiting the cURL homepage and downloading the executable from the downloads page. The Windows binary will require installation of some Microsoft Visual C++ libraries to work correctly.  cURL basicscURL itself is a command line tool that offers a means of communicating with various services at a protocol level. In particular cURL supports HTTP(S) communication, which means we can use it to query the HTTP based API service end points and issue API operations with a very fine level of detail. Before going ahead with the recipes, it is important to go over some basics of how to use cURL itself from a HTTP perspective.  Performimg an HTTP GET:A HTTP GET is what browsers typically do to download web pages and images whenever you go to a website. In the same manner you can issue a HTTP GET using cURL on a URL to get back the web page data. 

$ curl http://www.example.com

 Running the above with your favourite website should result in the HTML markup being returned. By default cURL will output the response body returned by the server directly to the terminal. We can also capture the output and send it directly to a file - this is effectively "downloading" the file or page. You can do this either by using the curl flag to specify an output file or you can just use the Linux redirection operator to capture the output, 

$ curl -o index.html http://www.example.com

$ curl http://www.example.com > index.html

  Performing a HTTP POST:cURL can also be used to perform a HTTP POST, which is what most HTML based forms use to send data to a remote server. There are a few ways to tell cURL what data to send when doing a POST, but we'll be concentrating on using the file based method to send data since many of the POST operations of the Rackspace Cloud API involves sending JSON or XML documents. To post a XML or JSON file we need to specify the Content-Type appropriately so the receiving end knows what to expect: 

$ curl -X POST -d @mydocument.xml -H "Content-Type: application/xml" http://www.example.com/form

$ curl -X POST -d @mydocument.json -H "Content-Type: application/json" http://www.example.com/form

 It is also possible to specify the data as a quoted string, but this can get unwieldy when doing so from the command line.  Performing an HTTP PUT:The HTTP PUT method is very similar to the HTTP POST method, except PUT operations normally imply some sort of storage request. For example uploading a object to a container is done using a PUT operation. When doing a PUT it is important to specify the HTTP Content-Type header of the object that is being uploaded so the receiving end knows what kind of file it is. cURL is relatively smart and will automatically pass through the required Content-Length headers to ensure the file is uploaded in a standard fashion. The syntax is as follows: 

$ curl -X PUT -T myobject.jpg -H "Content-Type: image/jpeg" http://www.example.com/upload

  Viewing the HTTP headers:With the API, quite often the operations will not return a response body, just response headers. Much of the usefulness of the API result is in the headers which contain useful information such as the HTTP response code. To view the HTTP response headers: Note: The -I option is the equivalent of a HTTP HEAD request, ie. -X HEAD. 

$ curl -I http://www.example.com

HTTP/1.0 302 Found

Location: http://www.iana.org/domains/example/

Server: BigIP

Connection: Keep-Alive

Content-Length: 0

  Viewing more HTTP debug information:At times it is useful to view the full HTTP request/response transaction, this can be done by using the verbose flag. Doing this will print out practically all the HTTP data that is sent back and forth including the request headers. This is quite useful for debugging purposes, 

$ curl -v http://www.example.com

* About to connect() to www.example.com port 80 (#0)

* Trying 192.0.43.10... connected

* Connected to www.example.com (192.0.43.10) port 80 (#0)

> GET / HTTP/1.1

> User-Agent: curl/7.21.3 (i686-pc-linux-gnu) libcurl/7.21.3 OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.18

> Host: www.example.com

> Accept: */*

> 

* HTTP 1.0, assume close after body

< HTTP/1.0 302 Found

< Location: http://www.iana.org/domains/example/

< Server: BigIP

* HTTP/1.0 connection set to keep alive!

< Connection: Keep-Alive

< Content-Length: 0

< 

* Connection #0 to host www.example.com left intact

* Closing connection #0

  Sending HTTP Headers:When doing a HTTP request it is sometimes useful to specify addition headers to give the server more information about the request you are making. With respect to the API a useful header to specify is the "Accept" header to indicate the type of response you'd like back, either JSON or XML. 

$ curl -v -H "Accept: application/xml" www.example.com

* About to connect() to www.example.com port 80 (#0)

* Trying 192.0.43.10... connected

* Connected to www.example.com (192.0.43.10) port 80 (#0)

> GET / HTTP/1.1

> User-Agent: curl/7.21.3 (i686-pc-linux-gnu) libcurl/7.21.3 OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.18

> Host: www.example.com

> Accept: application/xml

> 

...

  Authenticating with the APIBefore we can use any of the Rackspace Cloud APIs we must first authenticate ourselves to receive an authentication token. The token is a one-time secret that is needed when making calls to the various Rackspace Cloud APIs. The typical lifetime of a token is 24 hours and you will always get the same token whilst it is still valid. Note: Keep your token a secret as it is crucial to your cloud service security, otherwise, a user may get full access to your Cloud based services. To authenticate we will need to query the Cloud Identity API. Version 1.1 of the Identity API is the current stable release and will be used in this worked example. We will need the Cloud API username and key; instructions on how to locate these credentials are documented in our API key generation article. Authenticating with the Identity service requires POSTing a document to the Identity API containing your Cloud API credentials. It is possible to submit XML or JSON documents to the Rackspace Cloud API, however the remainder of this article will focus on using XML documents as it is more descriptive. The following is an example XML document saved as auth.xml: 

<?xml version="1.0" encoding="UTF-8"?>

<credentials xmlns="http://docs.rackspacecloud.com/auth/api/v1.1"

 username="johndoe"

 key="4e229b2e0789d9070e8411c9beee1c13"/>

 With the XML document ready we can now make the curl call to POST the document to the API end point. The service end point will depend on whether you have a US or UK based Cloud account: US customers: https://auth.api.rackspacecloud.com/v1.1/authUK customers: https://lon.auth.api.rackspacecloud.com/v1.1/auth The curl based call will look like the following for johndoe who is a US based customer: 

$ curl -X POST -d @auth.xml -H "Content-Type: application/xml" -H "Accept: application/xml" https://auth.api.rackspacecloud.com/v1.1/auth

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<auth xmlns="http://docs.rackspacecloud.com/auth/api/v1.1">

 <token expires="2012-01-17T03:52:09.000-06:00" id="3c5c8187-2569-47e0-8a11-edadd384e12b"/>

 <serviceCatalog>

 <service name="cloudFilesCDN">

 <endpoint publicURL="https://cdn2.clouddrive.com/v1/MossoCloudFS_c4f83243-7537-4600-a94d-ab7065f0a27b" v1Default="true" region="ORD"/>

 </service>

 <service name="cloudServers">

 <endpoint publicURL="https://servers.api.rackspacecloud.com/v1.0/123456" v1Default="true"/>

 </service>

 <service name="cloudFiles">

 <endpoint internalURL="https://snet-storage101.ord1.clouddrive.com/v1/MossoCloudFS_c4f83243-7537-4600-a94d-ab7065f0a27b" publicURL="https://storage101.ord1.clouddrive.com/v1/MossoCloudFS_c4f83243-7537-4600-a94d-ab7065f0a27b" v1Default="true" region="ORD"/>

 </service>

 </serviceCatalog>

</auth>

 From the above output, there are three important bits of information that will need to be noted for later use. In particular the following below: 

1. API token
2. Cloud Files public endpoint URL
3. Cloud Files CDN endpoint URL

 In addition, if you are intending to access Cloud Files from a Cloud Server in the same datacenter, it is useful to use the Cloud Files internal endpoint URL in lieu of the public one. This will allow the API calls go directly to the Cloud Files servers over the datacenter's servicenet private network. This has the benefit of the Cloud Server not incurring bandwidth costs and also better throughput rates to and from the Cloud Files storage servers.   Cloud Files cURL RecipesThe following are cURL based recipes that you can use with Cloud Files API to quickly and easily do various Cloud Files related operations. The recipes are divided into two parts: storage operations and the CDN specific operations. To be able to make any of the following API calls, the authentication token needs to be passed along with the request. The following authentication token will be used in the below recipes: 3c5c8187-2569-47e0-8a11-edadd384e12b. We will also assume that we will be submitting and receiving only XML documents.  Storage Recipes:The storage recipes will require the use of the Cloud Files service endpoint URL which was returned as part of the authentication process. The following recipes will use the following URL: https://storage101.ord1.clouddrive.com/v1/MossoCloudFS_c4f83243-7537-4600-a94d-ab7065f0a27b, please substitute your own.  Listing containers:Querying the Cloud Files storage endpoint will return a simple list of available containers, each on a new line. 

$ curl -H "X-Auth-Token: 3c5c8187-2569-47e0-8a11-edadd384e12b" https://storage101.ord1.clouddrive.com/v1/MossoCloudFS_c4f83243-7537-4600-a94d-ab7065f0a27b/

backup

cloudservers

images

static

 It is also possible to list the containers with more details including information such as the container size and the number of objects within the container by passing the format URL parameter: 

$ curl -H "X-Auth-Token: 3c5c8187-2569-47e0-8a11-edadd384e12b" https://storage101.ord1.clouddrive.com/v1/MossoCloudFS_c4f83243-7537-4600-a94d-ab7065f0a27b/?format=xml

<?xml version="1.0" encoding="UTF-8"?>

<account name="MossoCloudFS_c4f83243-7537-4600-a94d-ab7065f0a27b">

 <container>

 <name>backup</name>

 <count>1</count>

 <bytes>54770176</bytes>

 </container>

 <container>

 <name>cloudservers</name>

 <count>0</count>

 <bytes>0</bytes>

 </container>

 <container>

 <name>images</name>

 <count>3</count>

 <bytes>174686</bytes>

 </container>

 <container>

 <name>static</name>

 <count>0</count>

 <bytes>0</bytes>

 </container>

</account>

  Creating a container:Creating a container requires performing a PUT request to the storage URL and including the desired container name as part of the URL. In this case we'll be creating a new container called newcontainer: 

$ curl -X PUT -H "X-Auth-Token: 3c5c8187-2569-47e0-8a11-edadd384e12b" https://storage101.ord1.clouddrive.com/v1/MossoCloudFS_c4f83243-7537-4600-a94d-ab7065f0a27b/newcontainer

202 Accepted

 The request is accepted for processing.  Deleting a container:A container may be deleted by issuing a DELETE request, but keep in mind that only empty containers may be deleted. If a container currently has objects within it, then those objects must first be deleted. No content body is returned as part of this request, so it is useful to also include the verbose flag to determine if the delete was successful by verifying that a HTTP 204 response is returned. 

 $ curl -v -X DELETE -H "X-Auth-Token: 3c5c8187-2569-47e0-8a11-edadd384e12b" https://storage101.ord1.clouddrive.com/v1/MossoCloudFS_c4f83243-7537-4600-a94d-ab7065f0a27b/newcontainer

...


< HTTP/1.1 204 No Content

< Content-Length: 0

< Content-Type: text/html; charset=UTF-8

< X-Trans-Id: tx6eeb58f3dfa44f2e892505b711e8aefa

< Date: Wed, 01 Feb 2012 13:05:00 GMT

 Listing objectsQuerying the container in question will return a simple list of objects within that container. By default only the first 10,000 objects are returned. The following lists the objects of a container called images: 

$ curl -H "X-Auth-Token: 3c5c8187-2569-47e0-8a11-edadd384e12b" https://storage101.ord1.clouddrive.com/v1/MossoCloudFS_c4f83243-7537-4600-a94d-ab7065f0a27b/images

banner.jpg

cloud.png

rackspace.jpg

 It is also possible get a more detailed object listing to view additional information about the objects such as it's size and content-type. 

$ curl -H "X-Auth-Token: 3c5c8187-2569-47e0-8a11-edadd384e12b" https://storage101.ord1.clouddrive.com/v1/MossoCloudFS_c4f83243-7537-4600-a94d-ab7065f0a27b/images?format=xml

<?xml version="1.0" encoding="UTF-8"?>

<container name="images">

 <object>

 <name>banner.jpg</name>

 <hash>9ed61f72b1f3777ff01b7ce128a67244</hash>

 <bytes>26326</bytes>

 <content_type>image/jpeg</content_type>

 <last_modified>2012-02-01T12:47:22.911070</last_modified>

 </object>

 <object>

 <name>cloud.png</name>

 <hash>8b31a0109b2998a0e42efa29859bde24</hash>

 <bytes>106206</bytes>

 <content_type>image/png</content_type>

 <last_modified>2012-02-01T12:47:24.130690</last_modified>

 </object>

 <object>

 <name>rackspace.jpg</name>

 <hash>cbf00714f4dcc0724ddbe4028f76814e</hash>

 <bytes>42154</bytes>

 <content_type>image/jpeg</content_type>

 <last_modified>2012-02-01T12:47:25.235390</last_modified>

 </object>

</container> 

 It is possible to list more than 10,000 objects or to filter by specific objects by passing some additional URL parameter options. Please refer to the List Objects API documentation for more detailed information on the available parameters and how they work.  Downloading an object:Doing a GET request on the full path to an object will cause curl to effectively download the content. By default the content goes straight to the terminal. It is possible to pipe the data printed to the terminal for processing or to simply redirect the data to a file to effectively save the contents. The following example will download the cloud.png object from the images container to a local file of the same name by using the curl -o option to save the HTTP response body to a file: 

 $ curl -o cloud.png -H "X-Auth-Token: 3c5c8187-2569-47e0-8a11-edadd384e12b" https://storage101.ord1.clouddrive.com/v1/MossoCloudFS_c4f83243-7537-4600-a94d-ab7065f0a27b/images/cloud.png 

 % Total % Received % Xferd Average Speed Time Time Time Current

 Dload Upload Total Spent Left Speed

100 103k 100 103k 0 0 122k 0 --:--:-- --:--:-- --:--:-- 138k

  Uploading an object:To upload a new object to a container, simply perform a PUT request of the file to be uploaded along with any additional options that may be desired such as file content-type headers. The below example will upload a file called style.css to a container called static with a content-type of text/css. Note: Setting the correct content-type is important depending on where the object will be used. In the case of CSS files for example, having an improper content type could cause web-browsers to not parse the CSS when it served from the CDN resulting in an unstyled web page. 

$ curl -X PUT -T style.css -H "Content-Type: text/css" -H "X-Auth-Token: 3c5c8187-2569-47e0-8a11-edadd384e12b" https://storage101.ord1.clouddrive.com/v1/MossoCloudFS_c4f83243-7537-4600-a94d-ab7065f0a27b/static/style.css

<html>

 <head>

 <title>201 Created</title>

 </head>

 <body>

 <h1>201 Created</h1>

 <br /><br />

 </body>

</html>

 It is also possible to upload an object to make it appear as if the object is part of a directory structure. This is accomplished by naming the object with the full path including the directory components. This is useful when publishing containers to the CDN as the resulting CDN URL will appear as if it was part of a directory structure and is generally more organised. For example, repeating the above, but instead naming the style.css object so that it becomes css/style.css, 

$ curl -X PUT -T style.css -H "Content-Type: text/css" -H "X-Auth-Token: 3c5c8187-2569-47e0-8a11-edadd384e12b" https://storage101.ord1.clouddrive.com/v1/MossoCloudFS_c4f83243-7537-4600-a94d-ab7065f0a27b/static/css/style.css

<html>

 <head>

 <title>201 Created</title>

 </head>

 <body>

 <h1>201 Created</h1>

 <br /><br />

 </body>

</html>

  Deleting an object:To delete an object requires performing a DELETE request to the object to be deleted. It is useful to provide the verbose flag as the call does not return anything by default. A HTTP 204 No Content response code indicates a successful deletion. 

$ curl -v -X DELETE -H "X-Auth-Token: 3c5c8187-2569-47e0-8a11-edadd384e12b" https://storage101.ord1.clouddrive.com/v1/MossoCloudFS_c4f83243-7537-4600-a94d-ab7065f0a27b/static/style.css

...

< HTTP/1.1 204 No Content

< Content-Length: 0

< Content-Type: text/html; charset=UTF-8

< X-Trans-Id: tx08e07264230f46cea4bdbaf998e301c0

< Date: Wed, 08 Feb 2012 19:24:17 GMT

< 

* Connection #0 to host storage101.ord1.clouddrive.com left intact

* Closing connection #0

* SSLv3, TLS alert, Client hello (1):

  Performing a server side copy:By doing a server side copy it is possible to copy an existing object to a new storage location without having to go through the expense of performing the data upload from the client side; particularly for very large files. By combining server side copies with object deletion it is possible to do object moves and rename operations by first copying the object to the new location or name and then performing a deleting on the original. Copying is not restricted to a single container. The following example will copy the rackspace.jpg file to a new name of rackspace.jpeg as named in the Destination header: 

$ curl -X COPY -H "Destination: images/rackspace.jpeg" -H "X-Auth-Token: 3c5c8187-2569-47e0-8a11-edadd384e12b" https://storage101.ord1.clouddrive.com/v1/MossoCloudFS_c4f83243-7537-4600-a94d-ab7065f0a27b/images/rackspace.jpg

<html>

 <head>

 <title>201 Created</title>

 </head>

 <body>

 <h1>201 Created</h1>

 <br /><br />

 </body>

</html>

  Updating object headers:It is possible update certain HTTP headers corresponding to an object by performing a HTTP POST to the object path with the updated header. The most useful usage of this functionality is to correct an incorrectly set Content-Type header. Other headers that may also be set include the CORS and Content-Disposition headers. Note: It is also possible to update the headers by doing a server side copy and passing in the new header. To do this requires setting the destination of the copy to be the same as the source. The following is an example of how to update the Content-Type of an image to image/jpeg using the POST method: 

$ curl -X POST -H "Content-Type: image/jpeg" -H "X-Auth-Token: 3c5c8187-2569-47e0-8a11-edadd384e12b" https://storage101.ord1.clouddrive.com/v1/MossoCloudFS_c4f83243-7537-4600-a94d-ab7065f0a27b/images/rackspace.jpg

<html>

 <head>

 <title>202 Accepted</title>

 </head>

 <body>

 <h1>202 Accepted</h1>

 The request is accepted for processing.<br /><br />

 </body>

</html>

  CDN Recipes:Cloud Files maintains a separate CDN API web service endpoint specifically for CDN related operations. This URL is returned as part of the authentication process. The following recipes will use the following URL: https://cdn2.clouddrive.com/v1/MossoCloudFS_c4f83243-7537-4600-a94d-ab7065f0a27b, please substitute your own.  Listing CDN enabled containers: Performing a GET request on the CDN API URL will return a list of containers that have been CDN enabled at some point in their life. Containers that have never been CDN enabled will not appear on this list. The following will list all CDN enabled containers:  

$ curl -H "X-Auth-Token: 3c5c8187-2569-47e0-8a11-edadd384e12" https://cdn2.clouddrive.com/v1/MossoCloudFS_c4f83243-7537-4600-a94d-ab7065f0a27b

files

static

  CDN enabling a container:Before a container can have CDN operations performed on it, the container needs to be CDN enabled. This is accomplished by performing a HTTP PUT to the CDN URL and naming the container in question. Additional CDN related headers may be passed along at this point to initialise the content to certain CDN attributes such as container TTL and whether CDN logging should be enabled. If no additional CDN headers are passed along, the container will get enabled with the default values. Note: CDN enabling a container should not be confused with publishing a container. CDN enabling container simply makes it CDN aware so that it can be used with the CDN. By default CDN enabling a container also publishes it. The following will enable and publish the images container: 

$ curl -X PUT -H "X-Auth-Token: 3c5c8187-2569-47e0-8a11-edadd384e12b" https://cdn2.clouddrive.com/v1/MossoCloudFS_c4f83243-7537-4600-a94d-ab7065f0a27b/images

...

HTTP/1.1 204 No Content

Date: Wed, 15 Feb 2012 20:28:29 GMT

Server: Apache

X-CDN-URI: http://c12345.r49.cf2.rackcdn.com

X-CDN-SSL-URI: https://c12345.ssl.cf2.rackcdn.com

X-CDN-STREAMING-URI: http://c12345.r49.stream.cf2.rackcdn.com

X-CDN-Enabled: True

X-TTL: 259200

X-Log-Retention: False

Connection: close

Content-Type: text/plain; charset=UTF-8

  Viewing a container's CDN details:To view a containers CDN properties requires doing a HTTP HEAD request to the API CDN URL. Viewable information include whether the container is CDN enabled, if CDN logging is turned on and the currently set TTL as well as the various CDN domain names that can be used to reference content within the container. The following will list the CDN details of the images container: 

$ curl -I -H "X-Auth-Token: 3c5c8187-2569-47e0-8a11-edadd384e12" https://cdn2.clouddrive.com/v1/MossoCloudFS_c4f83243-7537-4600-a94d-ab7065f0a27b/images

HTTP/1.1 204 No Content

Date: Mon, 20 Feb 2012 19:39:41 GMT

Server: Apache

X-CDN-URI: http://c4965949.r49.cf2.rackcdn.com

X-CDN-SSL-URI: https://c4965949.ssl.cf2.rackcdn.com

X-CDN-STREAMING-URI: http://c4965949.r49.stream.cf2.rackcdn.com

X-CDN-Enabled: True

X-TTL: 259200

X-Log-Retention: False

Connection: close

Content-Type: text/plain; charset=UTF-8

  Updating a container's CDN attributes:A CDN enabled container may have it's CDN attributes updated by doing a HTTP POST request to the API CDN URL naming the container to be updated and passing along one or more of the attribute headers. Trying to perform a update of a container that has never been CDN enabled will result in a HTTP 404 error. The verbose option should be used to determine if the request was accepted as no response body is returned. The following are a list of CDN attributes that may be updated: 

X-CDN-Enabled: indicates whether the container should be published or not, an unpublished container will not be publicly visible. Note that any existing content cached within the network will still be accessible using the CDN URL until the content's TTL expires and it is removed from the network. Accepts a value of True or False.

X-TTL: indicates the container's TTL value in seconds. This setting is applied to the container itself and all objects within and controls how long the content is cached within the CDN. It is not possible to have per object TTL values. There is a minimum limit of 15 minutes and a maximum limit of 50 years.

X-Log-Retention: indicates whether the container has CDN logging enabled. These are W3C style HTTP logs for all CDN content requests for the particular container. Accepts a value of True or False.

 The following example request will unpublish a container called images: 

$ curl -v -X POST -H "X-CDN-Enabled: False" -H "X-Auth-Token: 3c5c8187-2569-47e0-8a11-edadd384e12" https://cdn2.clouddrive.com/v1/MossoCloudFS_c4f83243-7537-4600-a94d-ab7065f0a27b/images

...

< HTTP/1.1 202 Accepted

< Date: Mon, 20 Feb 2012 19:33:33 GMT

< Server: Apache

< X-CDN-URI: http://c4965949.r49.cf2.rackcdn.com

< X-CDN-SSL-URI: https://c4965949.ssl.cf2.rackcdn.com

< X-CDN-STREAMING-URI: http://c4965949.r49.stream.cf2.rackcdn.com

< Content-Length: 0

< Connection: close

< Content-Type: text/plain; charset=UTF-8

< 

  Purging an object:It is possible to force content removal from the CDN by issuing a CDN purge request by submitting a HTTP DELETE to the content to be purged. The purge request can only be done on a per object basis. The purge request will schedule a job with Akamai to have the indicated content removed from all member nodes of the CDN and can take some time to complete. It is possible to pass through the X-Purge-Email header together with a comma-separated list of e-mails so that a notification will be sent when the purge is completed. At the time of writing only 25 purges may be done per account per day. If a container level purge needs to be performed, please contact support via a ticket naming the container to be purged and we can do this on your behalf. If a notification e-mail is required, please also let us know the desired e-mail(s) to use. Note: Attempting to perform multiple purges on the same content whilst a previous purge is still running will result in a HTTP 400 error. The following will perform a CDN purge of the rackspace.png file from the images container with a notification e-mail set to user@example.com (the verbose option should be used as no response body is returned): 

$ curl -v -X DELETE -H "X-Purge-Email: user@example.com" -H "X-Auth-Token: 3c5c8187-2569-47e0-8a11-edadd384e12" https://cdn2.clouddrive.com/v1/MossoCloudFS_c4f83243-7537-4600-a94d-ab7065f0a27b/images/rackspace.png

...

> 

< HTTP/1.1 204 No Content

< Date: Mon, 20 Feb 2012 20:10:18 GMT

< Server: Apache

< Content-Length: 0

< Connection: close

< Content-Type: text/plain; charset=UTF-8

< 

* Closing connection #0

* SSLv3, TLS alert, Client hello (1):

 Summary:This article is meant to serve as a quick reference to the more common Cloud Files API requests and how to use them with cURL. For more information on other features that the Cloud Files API offers please refer to the our Cloud Files API documentation. The cURL techniques discussed in this article may also be used with our other Cloud based APIs and more generally for debugging HTTP and HTTPS based applications and web servers. Happy cURL-ing!