SQL Azure Team Blog : REST

Accessing the New Relational SDS with REST

davidrob — Fri, 20 Mar 2009 19:16:45 GMT

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:

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

Mike Amundsen is putting out lot of samples in his blog

Soumitra Sengupta — Wed, 16 Jul 2008 21:05:00 GMT

I just noticed that Mike has put out interesting code in his "life in lowercase" blog. It is good to see him add caching support to his provisioning client. Just put it on my "to play with during my vacation" list for the summer. Thanks Mike.

By the way, I responded to Mike's comments on SSDS and Astoria alignment. I do not disagree with Mike that one of the core values of SSDS is its simplicity. It is a tribute to the team that they have been able to keep it simple for developers to approach and use right away. I appreciate Mike's concern that aligning SSDS with Astoria could make SSDS lot more complicated. As I said in my response, the alignment does not mean that we are ditching the flex entity model. Once we release the aligned service, as a developer you will have a choice of staying with the flex entity model or add schemas where it makes sense to add schemas. We hope to provide this capability at the container level so you can choose to:

a. Keep all entities as flex entities
b. Keep all entities as typed entities
c. Have both typed and untyped entities and type entities with open or flex properties

The side effect is that the Astoria client library then becomes the default client library for developers to build their applications in Visual Studio. Still does not solve the problem of client libraries for Java, Ruby and PHP. I still got those on my plate to address.

If you look at the model above, you will notice that Amazon SimpleDB and SSDS only allows you to do a. today. GAE lets you do a. and b. We think c. is really very powerful and see all sorts of scenarios can be modeled using c. quite effectively.

At the time of writing this blog, I have not seen a plan for supporting EDM associations post alignment. I also want to point out that this alignment is actually good for EDM as it extends the current EDM model to cover untyped or flex entities. It is also important to point out that it is possible to bet on EDM without using EF. Astoria itself is an example of that.

Nice. David Robinson's MSDN Article about SSDS is out

Soumitra Sengupta — Tue, 15 Jul 2008 08:28:00 GMT

Just noticed this. David Robinson and Jeff Currier are the best writers on our team. Check it out.

Roger Jennings talks about SSDS in a Visual Studio Magazine Article

Soumitra Sengupta — Wed, 02 Jul 2008 10:34:00 GMT

Roger has an interesting article on SSDS in the latest Visual Studio Magazine here. It is really interesting to see the performance data between the SOAP and the REST end points of SSDS. It would be really interesting to dig into this.

One bit of correction - the SSDS flexible entity model was developed independent of EDM / EF and the Astoria model. At this point in time, both teams are working together to get this aligned.

I thought Dave Campbell in one of his press interviews had mentioned it but I could not find the reference. Sorry Roger. So here is an aswer to your question - SSDS is built using SQL Server 2005, SP2 as the starting code base. That is the starting point and we made changes to it. Over time, some of these changes will make its way into the SQL Server mainline and SQL Server 2008 will make its way into SSDS. We wanted to proceed in parallel as fast as we could and this was the best way to do it.

Jeff talks about upcoming ETag support in SSDS

Soumitra Sengupta — Sun, 22 Jun 2008 10:39:00 GMT

Jeff just sent me a note indicating that he has a post on the upcoming ETag support in SSDS. To be clear the bits are not yet released to operations. So we will have to wait a bit longer to get our hands on this feature. You can read all about it here. There are lots more cool things coming once Sprint 3 bits get released. So please stay tuned.

Tudor and Soumitra talk about SSDS value prop with Ryan

kellyalt — Fri, 02 May 2008 00:40:00 GMT

Agility (faster time to market), scale with your need and business ready SLA - Tudor and Soumitra highlight the core value propositions of SSDS on Channel 9. Thanks Ryan for doing the interview.

c'Urling on SSDS with Jeff

kellyalt — Mon, 14 Apr 2008 21:06:00 GMT

Jeff Currier just posted this blog post where he talks about using cURL with SSDS. This illustrates why we are taking an incremental approach. Using cURL with SSDS was not even on our radar till one of the first customers to go on the "restricted beta" wanted to use this. Jeff dug into it and helped them along. Now he is sharing this out with everyone else. When we started down this path, we were willing to be surprised. This is one of them. I am sure many more are on the way.