Azure Storage Services - StorageClient Library: Table Storage API Class Reference
The only “official” interface exposed by the Azure Storage Services is the REST protocol. The StorageClient sample provides “example” .NET wrapper classes for REST API operations managed by the System.Data.Services.Client library.
Note: Azure Table Storage is an ADO.NET Data Services provider, as described for SQL Data Services in my SQL Data Services to Gain New ADO.NET Data Services Client Model post of 1/6/2009. Details of DataServiceContext and DataServiceQuery classes from the System.Data.Services.Client namespace appear below the classes contained in TableStorage.cs.
Following is the class diagram for the classes contained in the StorageClient library’s TableStorage.cs class of the October 2008 CTP:
“Sample API” status update 1/7/2009: Wally B. McClure added the StorageClient thread to the Windows Azure forum on 1/6/2009. Wally has the same concerns as I about the status of the “Sample APIs” for table and blob storage:
MS has provided the StorageClient project as an example project to call the Azure APIs. Does MS plan for developers to use this class as a supported or maintained way to get to Azure? Will it be updated as necessary throughout the beta process by MS?
If not the StorageClient, will there be something else? I'm not looking for the StorageClient to do everything, but I do need some high level way to access Azure. If there is not highlevel API, preferably .NET, to get at Azure, this may slow adoption until someone produces a highlevel API to access Azure. The last thing I want to do is spend time writing lowlevel rest "stuff." [Emphasis added.]
The next question, is someone writing a .NET API for accessing azure outside of MS?
Microsoft’s Yi-Lun Luo responded on 1/6/2009 with the following answer:
Hello, while I can't 100% assure you at this time, we're working on high level .NET wrappers (and wrappers for other platforms). You can think [of] the StorageClient library as the first step. Today it doesn't provide all features the REST APIs give you (such as upload a single block), and maybe you'll discover several bugs, and you must expect a lot of break[ing] changes in the future (this is [a] CTP). But for most scenarios, the features it provides should be sufficient.
Finally, if you have further requirements, you can modify the source code. Anyway, personally I think even if the StorageClient is sufficient for your scenario, you still need to work with the REST APIs directly in some test applications, if it's only for learning purpose...
Wally was quite clear in his thread opener that “The last thing I want to do is spend time writing lowlevel [REST code].
Atom 1.0 site feed
1 comments:
I think the way the API is presented here has big advantage - anyone can see the lowest level. The SDK's StorageClient sample should probably come as second step in learning Azure storage API. Also, at the moment, I am not sure if the SDK provides a way to read a table with varying field sets (from row to row), which Azure beautifully supports.
PS. My experience was: I traced Azure SDK code in debugger, traced traffic in Fiddler, understood REST layer and then felt real comfortable with the SDK - but not before the pure REST drill
- sergei meleshchuk
Post a Comment