Friday, March 20, 2009

Accessing the New Relational SDS with REST

by davidrob via SQL Azure Team Blog on 3/20/2009 4:16:45 PM

Hi Everyone! This is Lev Novik, one of the architects on the SQL Data Services Team.

We get a number of questions about whether or not we have abandoned or downgraded REST access to SDS, and if so, why. To summarize: not at all --- rather than abandoning REST, we intend to support it in precisely the ways and places where we believe most people want it. Allow me to explain.

Consider an average (web) application today. Most often, it consists of a:

• client (often running in a browser),
• mid-tier business logic (often running in a web server), and
• back-end storage (often a relational database).

What are the protocols that are typically used? Well, the protocol between the client and the mid-tier is usually HTTP and often REST; the protocol between the mid-tier and the back-end storage is typically the native protocol of the back-end database.

Well, with SQL Data Services, the situation is quite similar. In these scenarios:

• SDS takes the place of the back-end database,
• mid-tier business logic is running maybe in Windows Azure, or maybe outside,
• and the client, well, the client is unchanged

In this world, we believe that you will continue to want to use the most powerful mechanism to talk from your mid-tier to SDS, together with the nicest database tools; and you will continue to want to be able to easily expose your web application to its clients in the most simple, elegant, and web-friendly way. This is why we concentrate on:

• Exposing TDS (SQL Server native protocol) as the full-featured way to talk to SDS
• Making it very easy for you to expose REST access to your SDS-based application.

To achieve the latter, we rely on ADO.NET Data Services (aka “Astoria”). Its very purpose in life is to make building data-driven REST services as easy as possible. For those who haven’t played with ADO.NET DS, I highly recommend it --- grab a favorite beverage, watch a quick introductory movie, get hold of a database of your own, and see what it takes to make a REST web service out of it (you might just have some of the beverage still remaining at this point).

But of course, your application is unlikely to be just a one-to-one mapping of a database --- you will want to build your own business logic, your own security policies, your own views, etc. ADO.NET Data Services allows you to implement these, and to make your creation into a real non-toy service (though this will certainly involve a few more trips into the kitchen!)

But that was SQL Server on your own dev box --- how does that work with SDS and Windows Azure? Well, we intend to make it work in much the same way:

1. Get set-up to develop Windows Azure services.
2. Create an SDS Database in the cloud, and load it up with your schema.
3. Create a Windows Azure Web Cloud Service Project in Visual Studio.
4. Add ADO.NET Data Service project item, and point it at the SDS Database (or at a local database with the same schema).
5. Develop your ADO.NET Data Service (security, biz logic, templates, etc)
6. Change the connection string to point to the real SDS Database in the cloud (if you used a local database for development)
7. Publish your service to Windows Azure.

And at the end, you have an SDS-based REST Service, configured just the way you like it!

Hope this made some sense!

--Lev