232 | Chapter 7: REST, Resources, and Web Services
- Buckets cannot be nested. There is one level of buckets, which contain objects.
However, we can fake such nesting by giving objects keys likeblog/2007/01/05/
index.html. Slash characters, though they often designate hierarchy in URIs, are
treated like any other character in object keys. We can even query keys by pre-
fix, so we can ask to list keys starting withblog/2007/01/05.
Amazon provides three different URI templates by which objects can be accessed. These
are genuine RESTful URIs; they refer to the resources themselves, and nothing else:
- http://s3.amazonaws.com/bucketkey/objectkey
- http://bucketkey.s3.amazonaws.com/objectkey
- http://bucketkey/objectkey
This last URI is an example of avirtual hosted bucket; by using a DNS name as a
bucket key, and pointing that DNS name ats3.amazonaws.com.via a CNAME, S3 will
recognize the bucket key from theHostheader and serve the appropriate object. This
makes it possible to serve an entire domain from S3, nearly transparently. If we cre-
ate a bucket calledimages.example.com, place a JPEG photo in it as an object called
hello.jpg, and ensure the proper CNAME is set up pointingimages.example.com.to
s3.amazonaws.com., then our image is accessible athttp://images.example.com/hello.jpg
with a standard web browser, just as if we had an HTTP server serving that URI.
Authentication
Because Amazon was not tied to the limitations of existing HTT Pclients, it did not
have to bow to the limitations of HTT PBasic or Digest authentication in web brows-
ers when creating S3. The S3 authentication protocol is a thin layer, adding an
HMAC signature to each request. After the message is signed, a header is added to
the HTTP request as follows:
Authorization: AWSAWSAccessKeyId:SignatureTheAWSAccessKeyIdvalue indicates the ID of the access key that the bucket owner
generated; it is tantamount to a user ID. TheSignaturevalue is the Base64-encoded
result of the HMAC calculation.
Alternative authentication options
S3 is a closed system; the owner of a bucket is billed for most operations on it.
Therefore, all requests to S3 must be signed or otherwise authorized by the bucket
owner, as he is the one ultimately responsible for payment.
However, signing each request can be inconvenient in some situations. A common
example is when an organization uses S3 as an asset server; usually the organization
would want the corresponding bucket to be world-readable. S3 includes access con-
trol lists (ACLs) for this purpose. As long as the owner is comfortable with being
charged for operations by anonymous users, he can give READ access to the AllUsers
group,which will eliminate the need for a signature.