A Close Look at the Rackspace Cloud Servers API and How it Compares to Amazon’s EC2 API

    The research done for this post was conducted by the Rackspace Cloud development team.

    When we released our Cloud Servers API a year ago, we wanted to adhere as strictly as possible to RESTful practice. We stuck to open, accepted web standards that existed to help take the guesswork out of the developer workload. We didn’t want to invent anything new but rather build things on well-defined standards. To share what we designed and to foster a more open cloud, we open sourced our Cloud Servers and Cloud Files API specifications under the Creative Commons 3.0 Attribution license – this is our commitment to having an open cloud.

    With that being said, sometimes it’s easier to understand the benefits of one API versus another by detailing out the differences. Rackspace Cloud Servers and Amazon EC2 are credited to be the most widely used cloud computing providers and we both have API’s, some similarities but mostly differences. In particular, EC2 has a number of features not currently available in Cloud Servers – the ability to upload an image, for example. Likewise, there are certain features on Cloud Servers that are not available on EC2 – the ability to schedule automated backups, for example, or server persistence after a shutdown.  At their heart, however, both services offer a standard set of features:

    • Launch, delete, and reboot servers
    • Create images of servers that can be used as “gold” images
    • Manage IP addresses associated with servers

    The purpose of this post is to provide a comparison of how this set of common features is exposed in the Cloud Servers and EC2 APIs.

    Feature Comparison

    RESTful Interface

    The Cloud Servers API is truly RESTful.  It makes very good use of the HTTP protocol. Every resource in the API (server, image, flavor) is identified by a unique URI. The interface to the API is based on the uniform subset of HTTP operations (GET, POST, PUT, DELETE) on these URIs. In contrast EC2 supports two APIs:  a SOAP based API which is strictly RPC and a Query API.  While the Query API supports REST-like queries it is not truly RESTful because it does not contain a uniform interface, instead of the uniform HTTP operations (GET, POST, PUT,..) it supports an arbitrary vocabulary of verbs (DescribeImages, DescribeInstances, CreateSnapshot, DeleteSnapshot). Additionally, all HTTP requests on the API hit a single URL, resources are not identified by a unique URIs.

    Web Service Contracts

    A web service contract specifies the operations and data types for an API. Contracts are important because they establish a well defined set of expectations between an API service and the clients that consume it. Contracts also help in versioning the API (see below).  Cloud Servers and EC2 APIs both offer support for human readable contracts in the form of Developer Guides and machine readable contracts that can be used to validate operations and to generate code. To define operations, the Cloud Servers API uses WADL for its machine readable contract and EC2 uses WSDL for its SOAP based API. Operations are not defined in a machine readable manner in EC2’s Query API. All APIs, however, define their entities (servers, flavors, images,etc.) in terms of XML Schema (XSD).

    Cloud Servers API contracts offer a greater level of detail in some important respects.  For example, when defining operations the Cloud Servers API defines what things can go wrong on a per operation basis: There are six distinct failures that can occur when requesting details about a server and eight distinct failures that can occur when changing an administrative password.  These possibilities are described both in the Cloud Servers Developer Guide and in the WADL.  EC2, on the other hand, defines a set of Error Codes in their API reference manual, but does not associate these codes to individual operations. Additionally, although WSDL offers support for associating faults with operations, EC2’s WSDL contract does not do so.  In EC2,  it becomes the responsibility of the client to determine what error conditions are possible when performing one operation or another.  This itself can be error prone – especially when one considers that error conditions may change from one revision of the API to the next.

    Cloud Servers API contracts also offer greater refinement when defining data types. For example, both Cloud Servers and EC2 Instances can be in a certain state:  the server is running, or it is building, it is suspended or it is in error.  Both APIs define an XSD type to capture this state:

    • Cloud Servers (ServerStatus):


    • EC2 (InstanceStateType):

    The big difference here is that the Cloud Servers type defines all possible values for the state and gives an explanation for what each means. In EC2, the state is defined as an integer and a string, it becomes the responsibility of the client to determine what the possible states are, and more importantly what it means for an instance to be in a certain state.

    Representation Formats

    The Cloud Servers API supports both XML and JSON for representing entities. Offering support for multiple representations allows different kinds of clients to interact with the API more easily. For example, for enterprise developers (particularly those using JEE and .Net)  having an XSD backed XML representation means writing significantly less code. For developers working with JavaScript and other dynamic languages, JSON is a lot more convenient.

    Both representation formats are supported fully in the Cloud Servers API.  It is possible, for example, to initiate a request by sending XML data and receive a response in JSON. The ability to support this use case may seem odd, but it is of particular importance to developers working on web applications.  These developers often work on back-end components, using frameworks that offer strong support to parse and generate XML, who’s only purpose is to provide information to a front-end JavaScript components more apt to support JSON efficiently. In most cases, the need to convert between these formats can be eliminated. Instead, conversion between the formats is achieved automatically by the API via HTTP’s content negotiation protocol.


    The Cloud Server’s API performs authentication via a simple token-based protocol.  A token can be obtained via a REST call from  a user’s credentials. The token is then passed in a header on every subsequent request. The HTTPS protocol is  used to prevent the token from being stolen. Token’s are ephemeral and eventually expire. At any time, the system may ask that a token be renewed by re-prompting for credentials.

    EC2’s authentication mechanism involves digitally signing every request. Each user is given an a key pair. Requests in both the Query and SOAP API must be strictly encoded and ordered –  in the Query API, HTTP query parameters must be in alphabetical order and their content must be strictly URL encoded. For example,

    Given the request:

    https://ec2.amazonaws.com/?Action=DescribeImages &ImageId.1=ami-2bb65342 &Version=2009-11-30 &Expires=2008-02-10T12%3A00%3A00Z &SignatureVersion=2 &SignatureMethod=HmacSHA256 &AWSAccessKeyId=

    A signature string must be created from the parameters.  The string must contain parameters in alphabetical order with URL encoded values:


    The string is signed and the Base 64 URL encoded signature is passed as a request parameter:

    https://ec2.amazonaws.com/?Action=DescribeImages&ImageId.1=ami-2bb65342 &Version=2009-11-30 &Expires=2008-02-10T12%3A00%3A00Z &Signature=&SignatureVersion=2 &SignatureMethod=HmacSHA256 &AWSAccessKeyId=

    Amazon’s authentication mechanism has the ability to securely validate requests without  the need  to use the HTTPS protocol. The mechanism, however, can be error prone and comes at the price of complicating client code.


    Both Cloud Servers and EC2 services set limits on certain operations to prevent abuse. In Cloud Servers, however,  these limits can be queried via the API.  For example, by default, Cloud Servers allows an account to create  no more than 50 servers per day – it is possible to determine this fact via the API.  Additionally, should an account create 50 servers within a day, the exact time when an additional server may be created can be queried programatically.

    Efficient Polling

    The Cloud Servers API and the EC2 API are both asynchronous.  This means that a request to perform an action does not wait until the action completes before returning.  To test the status of operations, developers must asynchronously poll to determine the state of a particular image or server instance.

    The Cloud Servers API provides a “changes-since” operation that can provide for efficient polling of groups servers or images with a single call. Changes-since works by providing developers with  a list of changes that have occurred since a particular point in time.  Additionally, Cloud Servers supports the standard  HTTP If-Modified-Since header which allows for a conditional GET operation for efficient polling of a single entity.

    Paginated Collections

    Both Cloud Servers and EC2 APIs support calls for requesting collections of servers and images. The Cloud Servers API additionally offers support for paginated collections:  When dealing with long lists of items a developer can request to receive a page of items of a certain size.  This is useful when presenting lists of items in a user interface since it is possible to request  a page at a specified offset – thus reducing the amount of memory that needs to be maintained on the client side.


    Both Cloud Servers and EC2 APIs support versioning.  In Cloud Servers, the base endpoint URL denotes the requested version:
    In the EC2 Query API, the requested version is passed as a parameter:

    https://ec2.amazonaws.com/?Action=DescribeImages&ImageId.1=ami-2bb65342 &Version=2009-11-30&Expires=2008-02-10T12%3A00%3A00Z &Signature=&SignatureVersion=2 &SignatureMethod=HmacSHA256 &AWSAccessKeyId=

    In the EC2 SOAP API, the requested version is determined by the namespace of the request XML:

    There are two features that sets the Cloud Servers API apart:  First, information about the current version and all available versions of the API can be queried.  Version information includes the current version status and pointers to the human readable and machine processable API contract for that version:

    Another subtle feature is that the API service has a well documented lifecycle. The lifecycle consists of an ordered set of version states:
    Having a query-able version allows developers to develop clients that can inform their users when a new version of the API is available.


    We hope the information provided has helped you understand our API better, why you would want to use it and what makes it different than that of Amazon’s EC2 API. Of course, everyone has their own preference and needs, and that is why we built our API on open standards and have followed a RESTful practice. We have no intention to lock anybody in and believe that solid, well-received cloud standards are the key to avoiding cloud lock-in. We encourage your continuous feedback and appreciate your contributions.

    Before leaving in 2016, Angela ran integrated marketing campaigns for Rackspace. She started in 2003 and did everything from Linux support, account management, sales, product marketing and marketing. She left Rackspace in 2005 to work for PEER 1 Hosting but returned in 2009 because she was interested in the cloud computing movement. Angela is a strong believer in the power of storytelling.


    1. A Close Look at the Rackspace Cloud Servers API and How it Compares to Amazon s EC2 API. › PHP App Engine

      […] The research done for this post was conducted by the Rackspace Cloud development team. . When we […]

    2. I think, the bandwidth details and billing/invoice details should have been exposed via API for rackspace cloud. Even today – “rename” the server does not work with rackspace API. Overall I agree a good attempt to get started very quickly.


    3. Lee, how do you figure their pricing is better? Take for instance, Amazon’s Large Instance Type compared to a 8192MB Rackspace Instance, both servers doing 500 GB out and 50GB in.

      Final Cost:
      Rackspace $444.40
      EC2: 324.98

    4. In the Authentication section, you mentioned that Amazon’s mechanism will be secure even if it doesn’t use HTTPS. Can you please elaborate on that?

    5. […] Rackspace, a web-hosting company that made its reputation on excellent technical/customer support, was one of the first legitimate entrants into cloud provisioning. Its VMs are cheaper and more capable that Amazon EC2 and not as limited as Google App Engine. Last year, Rackspace released a REST-based API to its cloud and provided it as open source. Here’s how the API matches up with Amazon EC2. […]

    6. In the end the API being REST or not really doesn’t matter. Client libraries get written that abstgract all that stuff away anyways. What really matters are the features available through the API. AWS has you guys beat hands down there, sorry to say.

      Get back to me when you have an EBS style detachable, snapshotable, resizable disk that isn’t tied to the instance size. DNS api?, remap IP addresses in < 10 seconds? 67gig ram instances? RDS?

      Alsao EC2 has server pwersistence after a shutdown ever since they came out with EBS backed AMI's so get facts straight before you go bragging about REST when what really matters is what is on the other side of the API.

      Not knocking rackspace, your cloudservers service is nice, it's just not useable for me until you have an EBS style service at least

    7. I agree with Ezra… in some sense, I don’t really care if you use REST or not. I’d recommend spending your time releasing drop-in SDKs for accessing your full API. For instance, a .NET sdk isn’t available for controlling cloud servers. Simple or not, Amazon does provide that sort of thing along with almost every programming language available. http://aws.amazon.com/sdkfornet/

      If Rackspace is lacking in any department, its the significantly higher time to market for my company since we have to spend time building basic projects to interop with your API. Despite your amazing support, its tough for us to avoid using EC2 when their API is better and is already rolled out in our development language.


    Please enter your comment!
    Please enter your name here