Like all of the Windows Azure storage services, the blob storage
service is accessible over a highly available, publicly accessible
REST API. Let’s take a look at how this works with the blob
storage API.All API access is through HTTP operations on a storage account URI.
For the Windows Azure blob storage service, that URI is of the form
http://<accountname>.blob.core.windows.net/<container-name>/<blob-name>.
For example, when accessing http://sriramk.blob.core.windows.net/test/helloworld.txt
(you can go ahead and access that URI in your browser now), “sriramk” is
the storage account, “test” is the container, and “helloworld.txt” is the name of the
blob.
API access falls into two categories:
Authenticated
Any operation that creates, modifies, or deletes anything must
be authenticated. In short, you sign the request with an HMAC of
your secret key, which the storage service verifies on its side by
trying to construct the same signature.
Unauthenticated
Unauthenticated requests are allowed for read operations if
the container they’re operating on has “full public read access”
turned on or read access for blobs turned on (the other visibility
option, “no public read access”). These requests can just be normal
HTTP GETs, and can be issued from
any dumb HTTP client (browsers are the key consumers here).
Sometimes you might find yourself being forced to make a container
public if your client of choice doesn’t support modifying HTTP
headers. An example would be early Silverlight versions that didn’t
support adding headers and, hence, users couldn’t perform
authenticated requests. Shared access signatures are useful in this
case.
When you access http://sriramk.blob.core.windows.net/test/helloworld.txt
through code, the URI goes through some DNS redirection and resolves to an
IP address in a Microsoft data
center; e.g., the previous example machine called sriramk.blob.core.windows.net currently
would redirect to
blob.sn1prodc.store.core.windows.net through a DNS
CNAME, and resolve to 70.37.127.110.
Note: It is important to not store these directly in your code, and to
always deal with only the properly formatted URIs. These DNS redirects
and IP addresses are internal implementation details, and can change
from time to time. In fact, the DNS redirection did change when support
for multiple geolocations was added.
