In the latest episode of my Microsoft Conversations series I talked with Pablo Castro about Astoria, a layer of middleware that makes data readable and writeable by means of a RESTful interface. Even if you don’t know or care about the buzzwords, it’s easy to show what Astoria does and to explain why it’s interesting. One of the sample databases configured to work with the experimental version of Astoria is a subset of the Encarta encyclopedia. You don’t have be a programmer or grok XML in order to appreciate the following dialogue with the Astoria-enhanced version of Encarta.
| What are Encarta’s topic areas? | encarta/encarta.rse/Areas |
<Area uri="Areas[5]"> <ID>4</ID> <Name>Life Sciences</Name> <Articles href="Areas[5]/Articles" /> </Area> ...etc... |
|
| The answer comes back in exactly the form shown here. It’s XML, but a very webby kind of XML that’s full of links that I’ve rendered as clickable. | |||
| So, what’s the fifth Area? | encarta/encarta.rse/Areas[5] |
<Area uri="Areas[5]"> <ID>5</ID> <Name>Sports, Hobbies, and Pets</Name> <Articles href="Areas[5]/Articles"/> </Area> |
|
| Every link asks a question, and gets an answer that embeds links to ask more questions. | |||
| OK, what are the articles in that area? | encarta/encarta.rse/Areas[5]/Articles |
<Article uri="Articles[761553558]"> <ID>761553558</ID> <Title>Aaron, Hank</Title> <Preview> Aaron, Hank, born in 1934, American baseball player, nicknamed Hammerin’ Hank, whose 755 home runs broke the all-time record previously held by ... </Preview> <Url> http://encarta.msn.com/encyclopedia_761553558/Hank_Aaron.html </Url> <Area href="Articles[761553558]/Area"/> <ArticleBody href="Articles[761553558]/ArticleBody"/> <Notes href="Articles[761553558]/Notes"/> <RelatedArticles href="Articles[761553558]/RelatedArticles"/> </Article> ...etc... |
|
A database with Astoria layered on top of it isn’t a web application, but it’s within shouting distance of being one, and you don’t even have to shout very loudly.
Pablo’s presentation at MIX is chock full of demos and explanations. Our podcast refers to and complements that presentation.
I’m not even close to being an expert in the underlying data access technologies, including ADO.NET, the Entity Data Model, and LINQ, so parts of the discussion quite frankly went over my head. Nor am I yet familiar with the tooling that’s required to wrap this kind of services layer around a plain data source. But I’m 100% clear that it’s a good idea, and a great example of RESTful web services — a book that Pablo Castro says is “required reading” for members of the Astoria team.
Hello,
I found your post really interesting especially in its pattern. You set questions in English and TRANSLATE them in URL (or vice&versa).
That points to one of the two biggest challenges coming to RESTafarians :
#1: URL Opacity sucks
=> As everybody embeds natural languages in URLs, let’s do it in a designed way => Let’s fix Operators to mean “proper noun”, “common noun”, “genitive”, “preposition”, “plural”…tobe able to write “the best article about REST by Jon Udell” in URL.
#2: URL need verbs
=> Excluding verbs cut half of the richness of natural languages. To link me to this article, I need to use “like” to post it within “the articles I like” different from “the articles I dislike” or “the articles I wrote when I was in Moscow.”
=> Verbs needs to be accepted in REST. You would POST things TO the “do” URL that will create things at the “Done” one.
Thanks again for your always enlightening post.
On verbs — careful Julien — what I think you are calling verbs seem to be demonstrative adjectives. Those are the articles “that julien likes” or “that julien dislikes” or “that julien wrote in Moscow”
I think you are justified to want these in your urls, but just to be clear they are not verbs that might tell the system to do something. They are adjectives that further categorize your resource information space.
Good post.