On Apr 5, 2006, at 5:31 PM, Dr. Ernie Prabhakar wrote:

> Thanks, Nic, Roy. The fog is clearing slightly. :-) The key issue
> appears to be:
>
> On Apr 5, 2006, at 4:26 PM, Roy T. Fielding wrote:
>> OTOH, a translation service like
>>
>> /convert?format=pdf
>>
>> can simply be a POST of file-upload with the response being the
>> converted representation.
>>
>>> However, that doesn't seem very RESTful.
>>
>> Why? POST is RESTful too, when it is used correctly.
>
> This is what confuses me. My (naive) understanding is that every
> URI represents a noun, that is, a resource. The URL:
>
> http://myhost.com/convert
>
> seems like it represents a verb, especially when given parameters:
>
> http://myhost.com/convert?format=pdf

Places are nouns, too. All you are doing is giving the URI of a service
that performs stateless conversions. The GET interface simply tells you
how to use the service (e.g., HTML form), there is no other resource
involved, and there is no sustained benefit across multiple invocations
(no reusable resources other than the service itself).

I hate to quote myself, but in sec 5.2.1.2:

"REST components perform actions on a resource by using a
representation to capture the current or intended state of that
resource and transferring that representation between components."

so what you have defined above is a one-resource RESTful service that
merely reflects a different shade of state back to the client.

> or even when given other nouns:
>
> http://myhost.com/convert?format=pdf&uri=http//example.com/
> get_it_here.html

That's a different beast -- it is a gateway, and it would "look"
more RESTful simply by choosing a different URI syntax, e.g.

http://myconverter.com/pdf/http://example.com/get_it_here.html

(naming scripts, including .cgi, and using path components versus
query parameters are all equivalent aside from some caching heuristics).
The presence of that gateway provides a parallel world of resources
(hopefully they would have the sense to block their own site
from being included within itself).

I guess you could say that is a more RESTful service than one that
only converted the input of forms. [OTOH, I am not entirely convinced
that "RESTful" is a meaningful term, since for me REST is a particular
architectural style with black&white constraints, whereas I use the
term "principled design" for discussion of tradeoffs. *shrug*]
I guess "more resources" would have to be "more RESTful".

> So, if I read Roy correctly, the service described by that URL is
> -- or at least could be -- RESTful. Does this mean that the belief
> "URLs must represent nouns" is a complete myth? Or is there
> something else going on here?

Don't get carried away. You won't find a constraint about "nouns"
anywhere in my dissertation. It talks about resources, as in
*re*sources, because that is what we want from a distributed
hypermedia system (the ability to reuse those information sources
through the provision of links). Services that are merely end-points
are allowed within that model, but they aren't very interesting
because they only amount to one resource. The really interesting
services provide many resources.

Note that this is just another way of restating Reed's law in
relation to Metcalfe's law.

http://en.wikipedia.org/wiki/Reed%27s_law

....Roy