Article:		Show Me the Code
Subject:		Accessing multiple ressources using GET
Date:		2007-01-19 12:19:00
From:		aronr
Response to: Accessing multiple ressources using GET
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.

Previous Message

Up

Next Message

• 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 ...