Attributes: Are the current REST-architecture tools limited to a tree-structure?

Question

Historically operating system directory-structures have been trees:

• C:
  • Windows
    • System32
  • Program Files
    • Common Files
    • Internet Explorer

And the REST architecture emulates the same thing:

• http://...//Thomas/
• http://...//Thomas/Mexico/Year2003/Photos
• http://...//Thomas/Mexico/Year2007/Photos
• http://...//Thomas/Finland/Year2005/Photos
• http://...//Thomas/Finland/Year2010/Photos
• http://...//Thomas/Finland/Year2010/Videos
• http://...//Thomas/USA/Year2005/Photos

But, looking the current structure, I need to make searches:

• All pictures that are not from Finland?
• All pictures taken in 2005?
• All pictures in timeline?

It is not efficient to do a REST-interface with every tree-hierarchy combinations. You need more efficient information management; you need an attribute-system rather than a tree-structure. (Oh, why the operating systems are not based on attributes?)

StackOverflow and Google seem to use attributes and syntax with "+"-marks like:

• http://www.stackoverflow.com/Tags/asp.net+iis7
• http://www.google.com/search?&q=iis7+asp.net

Today's frameworks like WCF and ASP.NET MVC have a good support for RESTful tree-structures. But is there support for attribute-structures? Wouldn't you call an attribute-structure still REST?

I would like to make an attribute-WebService and use it with a LINQ in Silverlight-client... Which is the best way to start? :-)

Answer 1

In order to create an effective REST interface you need to identify the resources that make sense for your client application. If you look at you use cases:

All pictures that are not from Finland? All pictures taken in 2005? All pictures in timeline?

The question you need to answer, is if this requires three resources or just one. I am assuming you want to have more than just these three queries, so therefore the most flexible solution is to define a generic resource which is a "collection of pictures".

/Thomas/pictures

From here, you want to be able limit contents of this resource by using query parameters.

/Thomas/pictures?country=not-finland
/Thomas/pictures?year=2005

In the case of the third item it may make sense to create a separate resource for that item.

/Thomas/PictureTimeline

There are other scenarios where it may make sense to create additional resource such as

/Thomas/FavouritePictures

The important thing is to identify what key concepts of your application you want to model as resources and then assign those resources an URL. Trying to do REST design via the URL space is going to make you bang your head against the wall.

Answer 2

Tuomas,

what you are looking for are URI matrix parameters: http://www.w3.org/DesignIssues/MatrixURIs.html http://stackoverflow.com/questions/401981/when-to-use-query-parameters-versus-matrix-parameters.

Jan