- From: Elliotte Harold <elharo@metalab.unc.edu>
- Date: Tue, 09 Jan 2007 14:36:18 -0500
- To: noah_mendelsohn@us.ibm.com
- CC: www-tag@w3.org
Looks good. The only thing I found questionable was the assertion that Indeed, use case 2 makes the point that the RESTful approach of assigning a URI to every resource can be inconvenient, particularly when large numbers of properties with parameterized names would each have to be represented in its own URI. It's relatively easy to motivate giving the printer its own URI; it's somewhat harder to decide whether to also assign a separate URI to each paper drawer in the printer, to each part of the printer that can jam, etc. I don't find it hard at all. I do see a lot of systems that are crippled by some needless stinginess with URIs. However, I see now reason we can't have (for example) http://laser1.example.com/drawers/1 http://laser1.example.com/trays/legal http://laser1.example.com/trays/letter http://laser1.example.com/toner http://laser1.example.com/queue http://laser1.example.com/queue/currentjob etc. You could use query strings instead if you prefer. However, especially int he case of a printer, where arbitrary files in arbitrary locations are unlikely to be installed, it seems reasonable to make use of the path part of the URL for addressing printer parts and features. -- Elliotte Rusty Harold elharo@metalab.unc.edu Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
Received on Tuesday, 9 January 2007 19:37:00 UTC