Azure storage holds three different types of data:
Blobs: For files or large amounts of textual data
Queues : For messages retrieved in a first-in, first-out manner
Tables: For holding objects (called entities in Azure terminology), bearing little resemblance to traditional storage mechanisms
Azure storage can be accessed by any application that can send an HTTP request, so don't think that you are confined to using this service with just .NET applications. Azure storage can also be tested locally by using the development storage. To access the Development Storage control panel, right-click the Windows Azure blue flag, and select the Show Development Fabric UI option.
The Development Storage management screen should then appear, showing each of the endpoints the storage service is running at (Figure 16-17).
You can see that Azure storage is divided into three different services of types Blob, Queue, and Table. The management screen shows each service's current status and endpoints. Tables differ in that they can be subdivided into containers.
To work with Azure storage, you have two options:
Make a request to the REST API directly.
Utilize the Windows Azure API, which makes REST requests behind the scenes.
So, you can see that ultimately you will be using the REST API or—er—–the REST API.
The Azure APIs will be more than suitable for most applications, but for integration purposes or where performance is paramount, you may want to use the REST API directly, because it will give you full control over your requests. However, before you rush off to develop your own REST API, here is a word of warning—don't underestimate the amount of work involved. Producing a class with enough functionality to work with a single type of Azure storage data will mean creating many different methods and can be quite boring, fiddly work.
3.143.241.133