Re: Draft of TAG Submission to W3C Workshop on Web of Services for Enterprise Computing

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