Project Codename "Astoria" – Microsoft takes a REST

Wednesday, October 24, 2007

“The goal of Microsoft Codename Astoria is to enable applications to expose data as a data service that can be consumed by web clients within corporate networks and across the internet. The data service is reachable over regular HTTP requests, and standard HTTP verbs such as GET, POST, PUT and DELETE are used to perform operations against the service”

In it’s simplest form, it really seems like a web data access layer to your database.  This also looks like it might be Microsoft’s offering for REST-style web service developers. Semantic web here we come!

There’s quite a few components you’ll need installed before you can start playing with it

  1. VS 2008 Beta 2
  2. SQL Server 2005 or Express
  3. Astoria Sept 2007 CTP
  4. ADO.NET Entity Framework Beta 2 (Runtime)
  5. ADO.NET Entity Framework (Tools)

Once you’ve downloaded all the required components, setup to get the data services up and running is a piece of cake.  You generate an Entity Data Model from your relational database, add a new “Web Data Service” to your ASP.NET application, and update a generic class to use your new entity model.  For step-by-step instructions, check out the Using Microsoft Codename Astoria document that comes with the installation.  In a matter of moments, you have your entire database wide-open and exposed over http.  Hmmm… this is a little scary – more on this to come…

You can then access your tables through a Uri pointer to specific tables.  You use expressions that query the database as the Uri.

The expressions are fairly intuitive.  Here are some examples:
<service>/Customers[1234] – returns the customer with the id 1234.
<service>/Customres[1234]/Orders – returns the sales orders for the customer with id 1234
<service>/Customers[ALFKI]/Orders[OrderDate gt '1998-1-1']  – returns all posted after 1/1/1998 for customer 1234

For a working example, check out the hosted Northwind data service here:[1]

There’s a lot more complex expressions which include paging, sorting, and the ability to expand elements in an entity that I’ll cover in future posts.

The operators map 1 to 1 with the binary operators in SQL:

Operator Description Example
eq Equal /Customers[City eq ‘London’]
ne Not equal /Customers[City ne 'London']
gt Greater than /Orders[OrderDate gt '1998-5-1']
gteq Greater than or equal /Orders[Freight gteq 800]
lt Less than /Orders[Freight lt 1]
lteq Less than or equal /Orders[OrderDate lteq '1999-5-4']

I would love to hear from some of the REST developers and get your feedback on Microsoft’s direction with these data services.  More to come on this exciting new technology soon, including more abstract concepts on what REST is, and what it means to your current development practices.  Needless to say, I have my apprehensions about it already.  It almost seems like a step backwards where business logic gets closer to the database and n-tier becomes 2-tier.  What do you think?


  1. http:// says:

    I wish I could understand the problem than REST solves.

  2. Maybe I’m off my track here but these REST services should only be used for public / non-secure transactions correct?

  3. MikeBosch says:

    At this point its pretty much wide open and all REST operations are supported by default. The only built in security is verifying if you’re authenticated or not. These are the questions I’ve been wrestling with. I’m not too familiar with the concepts of a REST architecture. I’d love to see how you’d implement a classic funds transfer scenario (transfer funds from Account A to Account B in an atomic transaction) with REST. I guess the scope of applications you would build with this is limited to read-only data (i.e. getting coordinates for a zip code).

    The Facebook API uses a REST-based interface as does the Amazon S3 API. There seems to be a trend here, although I might be making the mistake of assuming that Astoria is REST and REST is Astoria. What REST seems to boil down to is being a ROA (resource-oriented architecture) where everything is simplified to implementing four basic operations GET(select)/POST(insert)/PUT(update)/DELETE(delete). A little too simplistic for enterprise applications if you ask me.

  4. http:// says:

    500 :)

  5. http:// says:

    If you’re wondering the problem that REST solves, it’s excessive development time. It allows front end JavaScript/HTML programmers to work their Ajax magic without having to worry about the other stuff.

    The security of it is still a big question.

    But outside that, is there any reason developers should have to do more than play with a URL to get the data they want?

  6. MikeBosch says:

    “is there any reason developers should have to do more than play with a URL to get the data they want?”

    I think “get” is the keyword. I can definitely see a benefit there. But when you get into a developer just having to post to a Url to update, create, delete entities is where I think it gets more complicated as far as validation, processes, and business rules that determine the interactions of these entities. Isn’t that why we have RPC-style web services.

  7. Mike Chaliy says:

    Why do you think that Astoria(or REST) brings to us Semantic Web?

  8. MikeBosch says:

    I don’t think it necessarily brings the semantic web, but as Glenn mentioned, it certainly makes it easier to work with. Also, in a “me too” respect, most of what people consider “Web 2.0″ apps / services involve a REST protocol. Every entity is uniquely identified by a Uri. Well, that the argument for it anyways…

  9. http:// says:

    If you don’t get the point of REST, you might be interested in this:

  10. http:// says:

    I understand the GET part. how does astoria handle PUT and DELETE?

  11. StephanJade says:

    Cool post as for me. It would be great to read a bit more concerning that topic. Thnx for sharing that material.

Leave a Reply