Behind Microsoft's Astoria REST Framework

Posted by Dflying Chen on Sep 26, 2007

Sections

Operations & Infrastructure,

Enterprise Architecture,

Development,

Architecture & Design

Topics

.NET ,

Web Services ,

Data Access ,

REST

Tags

Astoria

In the latest Microsoft Architecture Journal (issue 13), Pablo Castro, a technical lead in the SQL Server team from Microsoft talked about several key features of the Microsoft’s REST Framework – Astoria.

As an introduction, Pablo said.

I think Astoria can be considered a good REST citizen. Astoria turns entities/records into resources, and those resources are addressable through the URI space that the server presents. Every resource can be obtained and manipulated through the HTTP uniform interface, and the system allows for simple layering and caching through the traditional methods that are used by the WWW.

Pablo tried to explain the reason why Microsoft started the Astoria project and why Astoria would be important and useful for the modern Web 2.0 concepts.

Serving user-interface elements is relatively straightforward from the server perspective. Most of the time these are simple file resources on the server, such as HTML or CSS files, media files. Serving data is another story. Until now, interaction with data was something that happened between the Web server and the database server; there was no need to expose entry points accessible from code running across the Web in a Web browser or some other software agent. This is where Project Astoria kicks in.

Like other REST frameworks, Astoria allows developers to use more ‘meaningful’ URL to access and manipulate the resources on the Internet. Astoria team has also set up a demo server which allows us to query the well-known Northwind database directly from HTTP.

http://astoria.sandbox.live.com/northwind/northwind.rse/Customers
http://astoria.sandbox.live.com/northwind/northwind.rse/Customers[ALFKI]/Orders

Astoria is integrated with Microsoft’s .NET framework perfectly while leveraging the existing framework infrastructure, as Pablo mentioned.

For .NET applications, the Astoria toolkit includes a client library that runs in the .NET Framework environment and presents results coming from Astoria services as .NET objects; not only is that easier for developers to use within the codebase of the client application, but it also integrates well with components that already operate on top of regular .NET objects.

The schema definition used by Astoria is an Entity Data Model (EDM) schema, which is supported directly by the ADO.NET Entity Framework. The Entity Framework also includes a powerful mapping engine that allows developers to map the EDM schema to a relational database for actual storage.

Still, Astoria will support other non-database, like LINQ-enabled data sources to be exposed through the HTTP interface.

Astoria provides a flexible and extensible entry point for developers to build their own custom business logics on top of the built-in resource graph, such as /Customers or /Products. E.g.

[WebGet]
public static IQueryable CustomersByCity(NorthwindEntities db, string city)
{
    if (city == null || city.Length < 3)
        throw new Exception(“bad city”);
    var q = db.Customers.Where(“it.City = @city”, new ObjectParameter(“city”, city));
    // add user-based filter condition to q
    return q;
}

Then we can use the following URL to access the service and specify a query parameter.

/MyCustomersByCity?city=Seattle

On the security side, Pablo and his team have made Astoria fully compatible with the ASP.NET authentication pipelines, which is very straightforward for you to integrate it with the existing projects.

Astoria looks into the ASP.NET API to find out whether a user is authenticated and to find out further details, so that an application that uses any authentication scheme properly integrated with ASP.NET will automatically work with Astoria.

For more information, please visit Astoria Team Blog and Pablo’s Blog.

• Older >