Article:		Show Me the Code
Subject:		Accessing multiple ressources using GET
Date:		2006-02-06 13:50:00
From:		mawi100
In your article you describe different methods for accessing a certain subset of bookmarks. While these subsets in your example are clearly defined ('20 most recent') I am wondering how that would work in the following situation: I want to retrieve information from about 50 different sensors (eg. air quality sensors distributed in a city) where these sensors can be randomly selected from a list or by certain criteria. Would it make sense to add each single sensor to the end of the URL (such as '/bookmarks/id1/id15/id16/...')? Or would it make more sense to POST a XML file that contains the searched sensor ids? I guess the latter approach would not comply with REST, while the first approach implies a hierachy which does not exist. What would be the best RESTful approach? Thanks a lot.

Previous Message

Next Message

• Accessing multiple ressources using GET
  2007-01-19 12:19:00 aronr [Reply]
  
  This may help: "users should not derive metadata from the URI itself". (From Hao He, "Implementing REST Web Services: Best Practices and Guidelines", http://www.xml.com/pub/a/2004/08/11/rest.html)

  
  That implies that the number or codes in the URIs used by your RESTful service to identify unique, individual sensor readings should not correspond to a physical numbering or coding scheme used by those readings. That's because that scheme could well change later on, or the service might need to support multiple numbering or coding schemes for such data.
  
  

  • Accessing multiple ressources using GET
    2007-01-19 12:13:48 aronr [Reply]
    
    The above should have read: "sensors or sensor readings" rather than just "sensors'.
    
    
    • Accessing multiple ressources using GET
      2007-01-19 16:47:43 aronr [Reply]
      
      One more followup (sign): According to Roy T. Fielding, it *can* be useful to have meaningful resource hierarchies, so the suggestion to not use specific codes for sensors in URIs is not meant to generally discourage that practice. According to his quote, cited on the RestWiki:

      
      "REST does not require that a URI be opaque. The only place where the word opaque occurs in my dissertation is where I complain about the opaqueness of cookies. In fact, RESTful applications are, at all times, encouraged to use human-meaningful, hierarchical identifiers in order to maximize the serendipitous use of the information beyond what is anticipated by the original application."

      
      http://rest.blueoxen.net/cgi-bin/wiki.pl?RestAndUriOpacity#nid1SK

      
      Specifically regarding providing sensor data, there is a RESTful service for earthquake engineering data whose API is published at:

      
      http://it.nees.org/library/data/neescentral-web-services-api.php

      
      Perhaps that might provide some guidance or at least inspiration for coming up with a URI hierarchy and conventions in your own application ...