rest-discuss : Messages : 5832-5861 of 19454

Hi all,

I'm taking my quarterly run at trying to properly grok REST, and as
usual have only succeeding in confusing myself. :-)  Perhaps you can
help.

I want to provide a web service that, say, converts HTML documents
into various formats.   The naive RPC method would seem to be to
create a special URL string for each type, e.g.:

	 /convert.cgi?format=pdf&document=mydocument.html
	 /convert.cgi?format=doc&document=mydocument.html
etc.

However, that doesn't seem very RESTful.  I would imagine the RESTful
alternative would be to:
a) PUT the initial resource; get a URL back
b) <do something to that URL>
c) Return the URL describing that resource
d) GET the final resource

But, if so, I can't figure out the RESTful way to do (b). Is there?
What am I missing?  Or have I completely misconstrued the problem?

-- Ernie P.

#5833

From: Nic <nferrier@...>
Date: Wed Apr 5, 2006 11:02 pm
Subject: Re: RESTful representation of side effects?

nferrier_tap...

"Dr. Ernie Prabhakar" <drernie@...> writes:

> Hi all,
>
> I'm taking my quarterly run at trying to properly grok REST, and as
> usual have only succeeding in confusing myself. :-)  Perhaps you can
> help.
>
> I want to provide a web service that, say, converts HTML documents
> into various formats.   The naive RPC method would seem to be to
> create a special URL string for each type, e.g.:
>
>  /convert.cgi?format=pdf&document=mydocument.html
>  /convert.cgi?format=doc&document=mydocument.html
> etc.
>
> However, that doesn't seem very RESTful.  I would imagine the RESTful
> alternative would be to:
> a) PUT the initial resource; get a URL back
> b) <do something to that URL>
> c) Return the URL describing that resource
> d) GET the final resource
>
> But, if so, I can't figure out the RESTful way to do (b). Is there?
> What am I missing?  Or have I completely misconstrued the problem?

How about - you send:

   POST /documents
   Content-type: text/html
   --header-end--
   <html>
   to be converted
   </html>

you get back:

   HTTP/1.1 201 Created
   Location: /documents/200010027889
   Content-type: text/html
   --header-end--
   <html>
   to be converted
   </html>

the response entity could be something indicating that the document
was accepted or the entity that you posted... it's really up to you.

Now you send:

   GET /documents/200010027889
   Accept: application/pdf
   --header-end--

and you get back the PDF version or a 406 (can't do that sort of
representation).


Nic Ferrier

#5834

From: "Roy T. Fielding" <fielding@...>
Date: Wed Apr 5, 2006 11:26 pm
Subject: Re: RESTful representation of side effects?

roy_fielding

Hi Ernie,

> I want to provide a web service that, say, converts HTML documents
> into various formats.   The naive RPC method would seem to be to
> create a special URL string for each type, e.g.:
>
>  /convert.cgi?format=pdf&document=mydocument.html
>  /convert.cgi?format=doc&document=mydocument.html
> etc.

That is confusing.  Why "document=mydocument.html"?  Is the server
translating the input file or is it getting the file from somewhere
else?  I could understand a gateway form like

     /convert?format=pdf&uri=http//example.com/get_it_here.html
or
     /convert/http://example.com/get_it_here.html

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.

>  I would imagine the RESTful
> alternative would be to:
> a) PUT the initial resource; get a URL back
> b) <do something to that URL>
> c) Return the URL describing that resource
> d) GET the final resource
>
> But, if so, I can't figure out the RESTful way to do (b). Is there?

That would only make sense if you want the document to be stored
as a new resource that is available from then on, and the converted
forms are available via different links and/or negotiation.
In that case, you want the Alternates header field, though similar
functionality can be accomplished within the body of a 201 response.

It is relatively easy to create an HTTP server module that
provides content-conversion on the fly for anything stored within
the system.  It then becomes a resource discovery problem (how does
the client know where to obtain all of these other formats?), which
is what Alternates or Link was intended to supply.

....Roy

#5835

From: "Dr. Ernie Prabhakar" <drernie@...>
Date: Thu Apr 6, 2006 12:31 am
Subject: Re: RESTful representation of nouns?

sandhyaprabh...

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

or even when given other nouns:

http://myhost.com/convert?format=pdf&uri=http//example.com/
get_it_here.html

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?

-- Ernie P.

#5836

From: Bill de h�ra <bill@...>
Date: Thu Apr 6, 2006 12:55 am
Subject: Re: RESTful representation of nouns?

bdehora

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
>
> or even when given other nouns:
>
> http://myhost.com/convert?format=pdf&uri=http//example.com/
> <http://myhost.com/convert?format=pdf&uri=http//example.com/>
> get_it_here.html
>
> 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?

/mydocument.html/pdf

Alternative if the service is on the same domain. All */pdf patterns map
   back to the code that renders out the pdf and take the rest of the
path. It's kinda idiomatic for some frameworks to centralise the service
under one url and take other urls as arguments not because of any design
considerations or separation of concerns but because the URL dispatching
is optimised for certain patterns that end up looking servicey.

Let's not mix up my name with what I do.

It's more than verb tunneling. One can then argue that putting conneg
crap in the URL is no better than putting verbal crap in there.

re services. If your service runs on it's domain and in spirit accepts
urls as arguments, then it's probably really a "service" (in the sense
that a translation house is a service). Technorati is an example of
service that fits the seperations of concerns idea (except it gives you
backlinks instead of PDFs).

cheers
Bill

#5837

From: "Dimitri Glazkov" <dimitri.glazkov@...>
Date: Thu Apr 6, 2006 1:49 am
Subject: Re: RESTful representation of nouns?

dimitriglazkov

On 4/5/06, Dr. Ernie Prabhakar <drernie@...> wrote:
> http://myhost.com/convert?format=pdf&uri=http//example.com/
> get_it_here.html
>
> 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?

IMHO, It _is_ a noun. I think you're being misled that "convert"
somehow makes the URL less valid than "/mydocument.html/pdf", proposed
by Bill. What does an English word have to do with the RESTfulness of
a resource?  If I replace "convert" with its equvalent in Klingon,
will that satisfy the REST gods? Yes, perhaps you could split hairs
and not have URL contain something as "verby"-sounding as "convert",
but as long as this URL returns a stateless representation of a
resource (which it does), it's hunky-dory with REST, AFAIK.  In fact,
this is a classic proxy layer with a twist -- it also converts
representation.

Disagree? Fire away :)

:DG<

#5838

From: "Roy T. Fielding" <fielding@...>
Date: Thu Apr 6, 2006 2:01 am
Subject: Re: RESTful representation of nouns?

roy_fielding

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

#5839

From: "Mark Baker" <distobj@...>
Date: Thu Apr 6, 2006 2:05 am
Subject: Re: RESTful representation of nouns?

gonga_thrash

On 4/5/06, Dr. Ernie Prabhakar <drernie@...> wrote:
> 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

http://myhost.com/convertor ?

The whole verb-in-the-URI-thing is just a rule of thumb that I found
seemed to help some brought-up-on-RPC types I know to convert to a
state transfer style.

Mark.
--
Mark Baker.  Ottawa, Ontario, CANADA.       http://www.markbaker.ca

#5840

From: Dr. Ernie Prabhakar <drernie@...>
Date: Thu Apr 6, 2006 2:17 am
Subject: Re: RESTful representation of nouns?

sandhyaprabh...

Hi everybody,

On Apr 5, 2006, at 7:05 PM, Mark Baker wrote:
> The whole verb-in-the-URI-thing is just a rule of thumb that I found
> seemed to help some brought-up-on-RPC types I know to convert to a
> state transfer style.

Thanks for all the comments, they all helped add a little bit of
clue, including this:

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

So, services (even those that look like verbs) can be stateless
resources, too, as long as they aren't implicitly masking -other-
resources?

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

Ah, I get it.  If, for example, it always returned the result as:

http://myhost.com/convert?result.html

That would be non-RESTful (er, unprincipled? :-), because it doesn't
actually create real resource.

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

Okay, that actually makes sense.  I now officially have at least one
more clue than I did before...

Thanks!

-- Ernie P.

#5841

From: "Roy T. Fielding" <fielding@...>
Date: Thu Apr 6, 2006 3:48 am
Subject: Re: RESTful representation of nouns?

roy_fielding

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

> So, services (even those that look like verbs) can be stateless
> resources, too, as long as they aren't implicitly masking -other-
> resources?

Er, services that "look like verbs" are just confusing -- the question
is whether they behave according to the uniform methods applied to them
or not.  If you send it a GET, what happens?  If you send it a POST,
what happens?  How about PUT?  As long as the service doesn't go out of
its way to violate some other constraint (such as GET resulting in a
modified resource state), then how it looks shouldn't matter.

>> 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
>
> Ah, I get it.  If, for example, it always returned the result as:
>
> http://myhost.com/convert?result.html
>
> That would be non-RESTful (er, unprincipled? :-), because it doesn't
> actually create real resource.

You mean, if it redirected (or gave 202 response with a link) the client
to a different resource called

     http://myhost.com/convert?result.html

right?  It would still be RESTful.  It just wouldn't be very useful,
since all that identifies is a resource whose state is the most
recently completed conversion.  OTOH, if that is the resource that
you happen to want (as in, for example, a monitoring app), then maybe
it is useful enough.

A better way to think of the problem is to work backwards from the
end result.  What do you want the state of the system to be at the
completion of N requests (potentially parallel, multiple clients)?

Hint: A RESTful system progresses from one steady-state to the
next, and each such steady-state is both a potential start-state
and a potential end-state.  I.e., a RESTful system is an unknown
number of components obeying a simple set of rules such that they
are always either at REST or transitioning from one RESTful
state to another RESTful state. Each state can be completely
understood by the representation(s) it contains and the set of
transitions that it provides, with the transitions limited to a
uniform set of actions to be understandable.  The system may be
a complex state diagram, but each user agent is only able to see
one state at a time (the current steady-state) and thus each
state is simple and can be analyzed independently.  A user, OTOH,
is able to create their own transitions at any time (e.g., enter
a URL, select a bookmark, open an editor, etc.).

....Roy

#5842

From: Nic <nferrier@...>
Date: Thu Apr 6, 2006 9:02 am
Subject: Re: RESTful representation of nouns?

nferrier_tap...

"Dr. Ernie Prabhakar" <drernie@...> writes:

> 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
>
> or even when given other nouns:
>
> http://myhost.com/convert?format=pdf&uri=http//example.com/
> get_it_here.html
>
> 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?

Oh that's just nomenclature.

Try:

    http://myhost.com/mydocument

instead.


Nic

#5843

From: Benjamin Carlyle <benjamincarlyle@...>
Date: Thu Apr 6, 2006 3:05 pm
Subject: Re: RESTful representation of side effects?

fuzzybsc

On Wed, 2006-04-05 at 15:37 -0700, Dr. Ernie Prabhakar wrote:
> I want to provide a web service that, say, converts HTML documents
> into various formats.   The naive RPC method would seem to be to
> create a special URL string for each type, e.g.:
>  /convert.cgi?format=pdf&document=mydocument.html
>  /convert.cgi?format=doc&document=mydocument.html
> etc.

REST is a model for managing state mutation and transfer in a large
scale distributed architecture. People often get caught up in whether a
simple conversion activity of this kind is RESTful. They want to add new
URIs to the process and store the result somewhere on the server side.
This is not useful. The starting point for understanding a RESTful
architecture is to think about the state that needs to be retained on
the server side in order to keep things ticking along. In this case and
cases like it, there is no server-side state. Because there is no
server-side state, there are no server-side resources that need to exist
to manage or delimit that state.

The server side does not retain the converted document, so it returns
the document in the HTTP response and forgets about it. If it wanted to
keep the document around for other users of the service to view, it
should store it and represent the stored state as one or more resources.
If it wanted to keep public statistics on the number or types of
documents converted, it should store statistical state and represent the
stored state as one or more resources.

The difference between REST and RPC in the null-state case is not very
wide, especially when we are already constraining ourselves to the
document transfer problem domain. The REST version on the wire looks
like this:
>> POST /doc2pdf
>> (doc document)
<< 200 OK
<< (pdf document)
The RPC version looks like this:
>> ConvertDoc2Pdf(doc document)
<< (SUCCESS, pdf document)

This difference is still important. If we think about what the software
looks like that invokes the request, REST looks like this:
	 resource = getResource("http://example.com/doc2pdf")
	 document = resource.POST(document)
RPC looks like this:
	 docConverter = getDocConverter("http://example.com/doc2pdf")
	 document = resource.ConvertDoc2Pdf(document)
The RPC approach allows for a lot more of the variation at the code
level to be translated into variation all the way down to the network
level and back up again to the application level on the server side.
REST takes a uniform approach, and only the code that wants to handle
things in a domain-specific way has to do so. The code that gets
messages to that code and directs them back away can be generic and
straightforward.

REST pushes unformity of verbs and message structure at the network
level, and in fact forces us to rethink the application level
significantly. If the uniform version works, why waste time inventing a
more specific or type-safe version? Why validate the whole data
structure down in some network stack when you can transport the raw data
to where it is used and only process what is needed when it arrives? Why
insist on converting a message into an intricate structure of data when
you are just going to reencode it again for transmission or display it
to a user? Why not just retain it as strings until you know what you
will do with it?

The difference between REST and RPC is much clearer when we add
server-side state to the picture and the existence of intermediataries
between server and client. This what Fielding's work is mostly about.
However, there is a world view in REST that says "types don't work on
the network unless everyone understands them". It says that html is
interchangable, but the xml schema you dreamed up yesterday is not. It
says only parse what you need to, and ignore what you don't understand.
It says that the network with all of it's different agencies and
opposing interests is not an environment where traditional
object-orientation works. When we look at what does work, we find
ourselves thinking about compatability in different ways.

REST is not the end goal. It is not an absolute good in it's own right.
It is the benefits of REST that cause use to follow its philosophy. REST
is better than object-orientation for the same reason as we have web
browsers instead of CORBA-browsers. Uniformity is key. Simplicity at the
network level is key. Managing state transparently as resources is
important for its own reasons, but when you are looking at stateless
services such as document converters they really don't come into the
picture that much.

Benjamin.

#5844

From: "Sandeep Shetty" <sandeep.shetty@...>
Date: Thu Apr 6, 2006 4:19 pm
Subject: Request Header vs. Query String

sandeep.shetty@...

Hey,

There are a lot of places on the web where I have seen people specify
client preferences (acceptable media types, languages, etc.) in the
Query String which has got me thinking about why this is
inappropriate. The obvious reason for why they do this is that there
is limited support for tweaking request headers in Browserland [3] and
all too easy (testing via browser, etc.) to add stuff to the most
easily editable data element - the URL. Another reason why they might
do this is if they consider the different data formats as separate
resources.

My understanding is that Request Headers are used for parametrising
the request [1] and the Query String is used for parametrising the
resource [2]. If this is the case then you cannot put information in
the Query String that belongs in the Request Header because the Query
String in some sense affects the identity of the resource but the
Request Headers don't (this is true if like me you believe that the
different formats are not separate resources).

Is this correct or am I way off?

Sandeep Shetty
http://sandeep.shetty.in/


[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.3
[2] http://www.gbiv.com/protocols/uri/rfc/rfc3986.html#query
[3] http://sandeep.shetty.in/2006/04/browserland-http.html

#5845

From: "Joe Gregorio" <joe.gregorio@...>
Date: Fri Apr 7, 2006 2:44 am
Subject: Re: Request Header vs. Query String

JCGregorio

On 4/6/06, Sandeep Shetty <sandeep.shetty@...> wrote:
> Hey,
>
> There are a lot of places on the web where I have seen people specify
> client preferences (acceptable media types, languages, etc.) in the
> Query String which has got me thinking about why this is
> inappropriate. The obvious reason for why they do this is that there
> is limited support for tweaking request headers in Browserland [3] and
> all too easy (testing via browser, etc.) to add stuff to the most
> easily editable data element - the URL. Another reason why they might
> do this is if they consider the different data formats as separate
> resources.
>
> My understanding is that Request Headers are used for parametrising
> the request [1] and the Query String is used for parametrising the
> resource [2].

Query parameters are a convenient way to construct URIs for
resources, for example, GET-based HTML forms. Look at these
two URIs:

    http://www.google.com/search?q=REST
    http://www.google.com/search?q=This+is+spinal+tap

I don't think you'd consider google.com one big resource.

I don't think trying to squeeze all request headers
under the label of "parametrising the request"
is really correct (think of  Cache-Control:
and Connection:). There *are* request headers, such as Accept:,
but I wouldn't refer to them
as "parametrising the request" as much as
"parametrising the respresentation".

> If this is the case then you cannot put information in
> the Query String that belongs in the Request Header because the Query
> String in some sense affects the identity of the resource but the
> Request Headers don't (this is true if like me you believe that the
> different formats are not separate resources).

If you do have a resource that does some form
of content negotiation, which is what we're talking
about here, it is still useful to have URIs for
particular representations:

    http://bitworking.org/news/WebServicesAndContentNegotiation

    -joe

--
Joe Gregorio        http://bitworking.org

#5846

From: "Sandeep Shetty" <sandeep.shetty@...>
Date: Fri Apr 7, 2006 8:21 am
Subject: Re: Request Header vs. Query String

sandeep.shetty@...

Hey Joe,

On 4/7/06, Joe Gregorio <joe.gregorio@...> wrote:
> On 4/6/06, Sandeep Shetty <sandeep.shetty@...> wrote:
> > My understanding is that Request Headers are used for parametrising
> > the request [1] and the Query String is used for parametrising the
> > resource [2].
>
> Query parameters are a convenient way to construct URIs for
> resources, for example, GET-based HTML forms. Look at these
> two URIs:
>
>    http://www.google.com/search?q=REST
>    http://www.google.com/search?q=This+is+spinal+tap
>
> I don't think you'd consider google.com one big resource.

google.com is the naming authority and /search is the resource. You
don't have to think of /search as one big resource that contains these
small resources specified via a Query String. You can think of it as a
resource that gives you some way of getting to other resources by
providing "identifying information" [1] in the Query String.

Note that both the URI's (including the query mark and the query
string after it) you mentioned *are used to identify* quasi-static [2]
resources which can be cached till the next time google updates its
index.


> I don't think trying to squeeze all request headers
> under the label of "parametrising the request"
> is really correct (think of  Cache-Control:
> and Connection:). There *are* request headers, such as Accept:,
> but I wouldn't refer to them
> as "parametrising the request" as much as
> "parametrising the respresentation".

I'm not giving it that label, the spec is:
"These (request-header) fields act as request modifiers," [3]

According to the spec [4]:
"Accept headers can be used to indicate that the *request is
specifically limited* to a small set of desired types, as in the case
of a request for an in-line image."

So the Accept header *is* a request modifier.

Also, Cache-Control [5] and Connection [6] are both general-header
fields and not request-header fields.


> > If this is the case then you cannot put information in
> > the Query String that belongs in the Request Header because the Query
> > String in some sense affects the identity of the resource but the
> > Request Headers don't (this is true if like me you believe that the
> > different formats are not separate resources).
>
> If you do have a resource that does some form
> of content negotiation, which is what we're talking
> about here, it is still useful to have URIs for
> particular representations:


I agree but only in the case of reactive (agent-driven) negotiation [7].


Sandeep Shetty
http://sandeep.shetty.in/


[1] http://www.gbiv.com/protocols/uri/rfc/rfc3986.html#query
[2] http://www.w3.org/DesignIssues/Axioms.html#Query
[3] http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.3
[4] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1
[5] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9
[6] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.10
[7]
http://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm#sec_6_3_2_7

#5847

From: Bill Venners <bv-svp@...>
Date: Fri Apr 7, 2006 3:13 pm
Subject: Re: Request Header vs. Query String

billvenners

Hi Sandeep,

On Apr 7, 2006, at 1:21 AM, Sandeep Shetty wrote:

> Hey Joe,
>
> On 4/7/06, Joe Gregorio <joe.gregorio@...> wrote:
>> On 4/6/06, Sandeep Shetty <sandeep.shetty@...> wrote:
>>> My understanding is that Request Headers are used for parametrising
>>> the request [1] and the Query String is used for parametrising the
>>> resource [2].
>>
>> Query parameters are a convenient way to construct URIs for
>> resources, for example, GET-based HTML forms. Look at these
>> two URIs:
>>
>>    http://www.google.com/search?q=REST
>>    http://www.google.com/search?q=This+is+spinal+tap
>>
>> I don't think you'd consider google.com one big resource.
>
> google.com is the naming authority and /search is the resource. You
> don't have to think of /search as one big resource that contains these
> small resources specified via a Query String. You can think of it as a
> resource that gives you some way of getting to other resources by
> providing "identifying information" [1] in the Query String.
>
> Note that both the URI's (including the query mark and the query
> string after it) you mentioned *are used to identify* quasi-static [2]
> resources which can be cached till the next time google updates its
> index.
>
I think there's some overloading of the term resource going on here.
The way I've come to think of it, a resource is that which is
identified by a URI. So if it's a different URI, it is a different
resource. Therefore, the following are two different resources:

http://www.google.com/search?q=REST
http://www.google.com/search?q=This+is+spinal+tap

My definition of resource comes from the HTTP perspective. You said,
"You don't have to think of /search as being on big resource..." To
me, you're not talking about the HTTP perspective here, but about how
humans would think of the information architecture of Google. I think
that's important to consider when designing a web app, because the
URI is part of the user interface. URIs can be designed to help the
user understand and better navigate the site. But users don't think
in terms of resources. For lack of a better word, I'll use "content."

As an illustration, I posted a question to this list recently about
whether it made sense to consider personalization of a resource a
representation of that resource. I eventually realized that the
trouble with that approach is that if you have 1000 ETags for 1000
different personalized versions of a resource, and a proxy has all of
them cached, the If-None-Match request header would likely be bigger
than size of the representation. That defeats the purpose of caching,
which tells me that the number of possible representations, and
therefore ETags, for each resource needs to be fairly small.

So now, if you search Google for REST and hit this page on one of my
sites:

http://lejava.artima.com/articles/rest_easy

I'll notice that the referrer was:

http://www.google.com/search?q=REST

And I'll redirect the browser to:

http://lejava.artima.com/articles/rest_easy?q=REST

This URI will show the same article, but with the term "rest"
highlighted. From the HTTP perspective, these are two different
resources:

http://lejava.artima.com/articles/rest_easy
http://lejava.artima.com/articles/rest_easy?q=REST

But from the user's perspective, they are two different views of the
same piece of content, which is an article about REST. Therefore, the
query string parameterizes the content, from the user's perspective,
but not the resource. From the HTTP perspective, a URI is opaque, and
each unique string identifies a unique resource regardless of whether
it contains a question mark.

Does this way of thinking about the term "resource" sound correct?

Bill
----
Bill Venners
Editor-in-Chief
Artima Developer
http://www.artima.com

#5848

From: Jon Hanna <jon@...>
Date: Fri Apr 7, 2006 4:03 pm
Subject: Re: Request Header vs. Query String

hack_poet

Bill Venners wrote:
> Does this way of thinking about the term "resource" sound correct?

Pretty much, though I'd say that
http://lejava.artima.com/articles/rest_easy and
http://lejava.artima.com/articles/rest_easy?q=REST *could* refer to
different resources. They could also be the same resource, just as two
names could identify the same person, two C++ pointers could point to
the same object, etc.

For the most part we should of course assume that the two are different
resources (the aliasing will remain hidden from us).

#5849

From: "Sandeep Shetty" <sandeep.shetty@...>
Date: Fri Apr 7, 2006 4:35 pm
Subject: Re: Request Header vs. Query String

sandeep.shetty@...

Hey Bill,

On 4/7/06, Bill Venners <bv-svp@...> wrote:
> I think there's some overloading of the term resource going on here.
> The way I've come to think of it, a resource is that which is
> identified by a URI. So if it's a different URI, it is a different
> resource. Therefore, the following are two different resources:
>
> http://www.google.com/search?q=REST
> http://www.google.com/search?q=This+is+spinal+tap

This is what I'm saying as well.

> My definition of resource comes from the HTTP perspective. You said,
> "You don't have to think of /search as being on big resource..." To
> me, you're not talking about the HTTP perspective here, but about how
> humans would think of the information architecture of Google. I think
> that's important to consider when designing a web app, because the
> URI is part of the user interface. URIs can be designed to help the
> user understand and better navigate the site. But users don't think
> in terms of resources. For lack of a better word, I'll use "content."

Oh! I wasn't going down that road. I was just trying to explain to Joe
(who said "I don't think you'd consider google.com one big resource."
by which he meant something like "When you say that the Query String
is used for parametrising the resource, do you think the Query String
in http://www.google.com/search?q=REST or
http://www.google.com/search?q=This+is+spinal+tap is parametrising
google.com"?) that parametising the resource in a sense meant creating
identifiers to new resources (which could be sub-resources or
orthogonal resources).

> So now, if you search Google for REST and hit this page on one of my
> sites:
>
> http://lejava.artima.com/articles/rest_easy
>
> I'll notice that the referrer was:
>
> http://www.google.com/search?q=REST
>
> And I'll redirect the browser to:
>
> http://lejava.artima.com/articles/rest_easy?q=REST
>
> This URI will show the same article, but with the term "rest"
> highlighted.

This is not how I would do this. You could do this in a cache friendly
way on the client side (with javascript using document.referrer) and
not create a new resource just for highlighting search terms.

> From the HTTP perspective, these are two different
> resources:
>
> http://lejava.artima.com/articles/rest_easy
> http://lejava.artima.com/articles/rest_easy?q=REST
>
> But from the user's perspective, they are two different views of the
> same piece of content, which is an article about REST. Therefore, the
> query string parameterizes the content, from the user's perspective,
> but not the resource. From the HTTP perspective, a URI is opaque, and
> each unique string identifies a unique resource regardless of whether
> it contains a question mark.

The Query String is parametrising the content from the user's
perspective and not the resource because *you* designed it that way.
You could do it in the way I mentioned above and that would not be the
case.

Let me re-state what I meant in my first post [1]:
Request modifiers should not be put in the Query String because
request modifiers are not supposed to affect the identify of a
resource. When you put request modifiers in the Query String you are
creating new resources where you shouldn't.

Sandeep Shetty
http://sandeep.shetty.in/

[1] http://groups.yahoo.com/group/rest-discuss/message/5844

#5850

From: "Sandeep Shetty" <sandeep.shetty@...>
Date: Fri Apr 7, 2006 4:49 pm
Subject: Re: Request Header vs. Query String

sandeep.shetty@...

On 4/7/06, Sandeep Shetty <sandeep.shetty@...> wrote:
> Let me re-state what I meant in my first post [1]:
> Request modifiers should not be put in the Query String because
> request modifiers are not supposed to affect the identify of a
> resource. When you put request modifiers in the Query String you are
> creating new resources where you shouldn't.

Case in point: http://developer.yahoo.com/common/phpserial.html#outputparam


Sandeep Shetty
http://sandeep.shetty.in/

#5851

From: "Koranteng Ofosu-Amaah" <amaah@...>
Date: Fri Apr 7, 2006 6:36 pm
Subject: On coodination costs and human factors

amaah1

In an atypically verbose exposition, Matchmaker Roy Fielding propounded thusly:

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

Similarly, Layer Stripper Bill de Hora recently flirted in this way:

"Some people when faced when a distributed programming problem, think
'I know, I'll expose a new service interface.'

Now they have n-squared problems."

<http://www.dehora.net/journal/2006/03/now_they_have_nsquared_problems.html>

View Sourcerer Joe Gregario almost in passing shined a light on some
cobwebs (caching and authentication):

"In the process of implementing httplib2 I also discovered some rough
spots in HTTP implementations."

<http://www.xml.com/pub/a/2006/03/29/httplib2-http-persistence-and-authenticatio\
n.html>

Putting these together and handwaving as usual...

It strikes me that the first two statements are all about changing the
frame and making economic arguments for REST, namely constraining
system design to resources, identifiers and uniform interfaces in
order to lower coordination costs... ergo the web style as an enabler
of Reed's Law.

I hadn't seen such explicit harkening to Metcalfe and Reed in the past
even though there's has always been this notion of REST as
incorporating end-to-end principles. I too have argued in this vein
about a complexity and integration argument for REST.

In a similar thread Benjamin Carlyle put it thusly "Uniformity is key.
Simplicity at the network level is key. Managing state transparently
as resources is important for its own reasons"

Intuitively, the argument about applying architectural constraints to
get payoffs in terms of leverage has a lot of appeal to engineers. It
seems however that we need some economists to weigh in here with some
options pricing theory or other to give more heft to these arguments.
Often, decisions about software systems are not made by engineers but
rather by financiers and it helps to speak their language.

Instead of Reed's notion of group forming, it seems the argument by
analogy for REST is about application integration and the barriers
that obtain in that sphere.

Now I like the large numbers that we can throw out in these
reformulations. The thing is that Andrew Odlyzko says that both
Metcalfe and Reed's law are bunk despite their evident appeal and
ability to dazzle venture capitalists.

<http://www.dtc.umn.edu/~odlyzko/doc/metcalfe.pdf>

In that paper he sets out to get quantitative measurements and hard
data and puts the value of communication networks at nlog(n) which is
nothing to sneeze at, better than Sarnoff's linearity but far less
than Metcalfe and Reed's estimates. Now Odlyzko was measuring the
utility of the internet which encompasses more than the web and you
can argue following Sam Ruby that the email and peer-to-peer styles,
whether expressed as, Bittorrent, Skype or usenet, are the true
winners in his numbers... Also you could argue with his methodology
and I have my own quibbles, but it's a brave man who takes on
Odlyzko... Thus I'll take his numbers in my handwaving, acknowledging
after all that the web was the key enabler and popularizer of the
internet.

This gets me to the third quote from Joe, namely the perennial rough
spots and implementation quirks that are our daily bread as engineers
trying to design and produce systems for the web.

We see daily abuse of HTTP and there are annoying glitches with the
libraries and implementations that exist and also with what is
deployed in the real world. Perhaps this is because REST is the web
style rather than the programming model and consequently enforces very
few presciptions.

Now it seems to me that this is about the place where theory meets
practice and we get into the realm of pragmatism and leverage. In the
wild we see

- the difficulties of interoperation
- differing interpretations of specifications if indeed specs are read
- backward compatibility constraints e.g. for leverage and adoption,
HTTP 1.1 had to accomodate some of the pitfalls in HTTP 1.0
- difficulties in authoring structured data
- configuration and deployment issues (mime types, content negotiation etc)
- competition with other styles, the web style exists in a marketplace
of architectures
- vested interests and economic models e.g. limits imposed by shared
hosting providers, assymetry of some broadband networks etc

With this in mind, I wonder if I can come up with a stab towards
Koranteng's postulates on coordination costs

1. there is a natural dampening factor in the utility of distributed computing

We can use Odlyzko's numbers as the lower bound in practice of network
effects and Reed's law as the theoretical limit (with Metcalfe being a
great popularizer).

I happen to be reading Graham Green's The Human Factor and, looking
through some of the issues that hinder adoption, many of them could be
summarized as comprehension or human variability hence I'll
characterize the issue as the human factor. All that is left is to
augment with some Black-Scholes options thinking and finacial
derivatives to package to CEOs

2. the human factor in technology adoption is sizable and its effect
can be measured. Moreover I would argue that it should be recognized
as an explicit architectural constraint in the design on software
systems.

3. In the realm of distributed computing, this human factor is bounded
by Odlyzko's limit and Reed's law.

Mathematicians can derive the correct coefficient for me... 1 / n log(n) ?

The rest as they say is advocacy and implementation details...

We are operating with imperfect specifications, imperfect frameworks
and imperfect implementations. REST as laissez faire distributed
computing doesn't acknowledge these costs as architectural constraints
but rather seems to go about it by encouraging best practices and
hoping that by existence proof, people will come to it... If you look
at the high level requirements that have been articulated

- Simple protocols for authoring and data transfer
- textual formats for protocol and some exchanged hypermedia
- Sensitive to user-perceived latency
- Mark Baker's talk about "principled sloppiness" (i.e. "must-ignore
style extensibility")...

We don't tend to enforce much of these things in protocol. I wonder
what other best practices can lower coordination costs and if they can
be encoded in protocol to remove the human factor...

Anyway food for thought...

If anything this enables me to add Reed's insight to my growing
taxonomy of the web style which some in this list may have come
across.. namely

there's a tag: REST

there's a slogan: the web style

there's a Holy Book: Architectural Styles and the Design of
Network-based Software Architectures

there's a Reverend: HTTP

there's a choir: the HUHXtable quartet (HTTP, URI, HTML, XML)

there are Four Horsemen: GET, POST, PUT, DELETE

there are prophets: (you know who you are)

there are pillars: Resource Modeling, Idempotency etc

there are priests and tax collectors: the caching and other
intermediaries. Ergo "Render unto Ceasar that which is Ceasar's"
recast as the notion of "giving visibility to intermediaries".

there are angels and demons: a band of Apaches and various HTTP
libraries which are alternately sources of delight and exasperation

there's a Messiah: the browser (which comes with various pretenders,
Firefoxes, Great Explorer's, Viking Operas and Fruity Safaris)

there are red herrings: url opacity etc

there are false gods: WS-*, crusty old architectures of appropriation etc.

there's the wilderness and prodigal children: WebDAV?

there's immaculate conception: the virtuous XML

there are worldly travellers: the three mobile kings JavaScript, Java
Applet, ActiveX (some discredited)

there are scrappy offspring: Atom, RSS and Atompub

there are gruesome Philistines: implementation details such as
Structured Data, Character Encoding, Security

there are elevator pitches, Cliff's notes and ballads: Sir Tim's
lullaby of Web Architecture 101 is quite reasonable

<http://www.w3.org/2005/Talks/1110-iswc-tbl/#(4)>

there's myrrh and frankincense: the web as conversation

and now there's the promised land: Reed's Law as the land milk and honey

Parting digression: I noticed last year that Roy produced a white
paper about JSR 170 (Java Content Repository) for his day job (pun
intended) applying principled constraints to the modeling of content
repositories.

<http://www.day.com/etc/medialib/day_download_documents/white_papers.Par.0001.Fi\
le.tmp/JSR_170_White_Paper.pdf>

I've been curious about the surprising inertia behind that
specification having played with IBM implementations in the past few
years. Perhaps though the immaturity of that space is a tribute to
some of these arguments about coordination costs applied to the
marketplace of data (relational, object relational, XML, SQL, XPath,
XQuery, ActiveRecord, ODMA, Spring, Hibernate, SDO etc).

I wonder if the Atom store dream is the way to go, namely rather than
apply the constraint of an api and a language, Java, in a world in
which we have a Tower of Babel of languages and persistence
frameworks, it makes  more sense to focus on wire protocol (as in Atom
Publishing protocol) and wire format say Atom. In other words the
greater payoff would be not in establishing a programming model (the
JCR) but rather in moving to Atompub which is agnostic on the
underlying programming model and lowers the coordination costs by
stripping a layer of comprehension from the mix. All this of course is
modulo the quirks of compound documents, media collections etc...

Anyway having written this much, it's probably worth blogging at some point...

Comments welcome...

--
Koranteng
--
Koranteng's Toli  - http://koranteng.blogspot.com/

Reply | Messages in this Topic (1)

#5852

From: Bill Venners <bv-svp@...>
Date: Fri Apr 7, 2006 7:45 pm
Subject: Re: Request Header vs. Query String

billvenners

Hi Sandeep,

> This is not how I would do this. You could do this in a cache friendly
> way on the client side (with javascript using document.referrer) and
> not create a new resource just for highlighting search terms.
>
Yes, you're right. I have a fear of JavaScript that I need to get
over. My concern is the test matrix. I like the fact that I can check
what comes out of:

http://lejava.artima.com/articles/rest_easy?q=REST

And know that the XHTML is correct when it leaves the server. But
truth is I plan to do JavaScript stuff anyway, so I need to figure
out a way to test what the XHTML looks like after the JavaScript
runs. Then I may as well do the keyword highlighting that way.

>>
>> http://lejava.artima.com/articles/rest_easy
>> http://lejava.artima.com/articles/rest_easy?q=REST
>>
>> But from the user's perspective, they are two different views of the
>> same piece of content, which is an article about REST. Therefore, the
>> query string parameterizes the content, from the user's perspective,
>> but not the resource. From the HTTP perspective, a URI is opaque, and
>> each unique string identifies a unique resource regardless of whether
>> it contains a question mark.
>
> The Query String is parametrising the content from the user's
> perspective and not the resource because *you* designed it that way.
> You could do it in the way I mentioned above and that would not be the
> case.
>
I agree. I am aiming for RESTful and user-friendly URL design for
content-oriented sites.

> Let me re-state what I meant in my first post [1]:
> Request modifiers should not be put in the Query String because
> request modifiers are not supposed to affect the identify of a
> resource. When you put request modifiers in the Query String you are
> creating new resources where you shouldn't.
>
I think I see. I believe I was thrown I was thrown by the word
"creating." Basically, I think you're saying that you shouldn't
specify data to be used for content negotiation in query parameters
because each set of query parameters embodies a different URI, which
implies a different resource. Whereas request headers parameterize
the same URI, which implies the same resource. Is that correct?

If so, I agree with that, though I am leaning away from most content
negotiation anyway. For usability reasons, I think an article
translated into different languages should each have a different URI
for each language. Likewise for usability I think the PDF form of an
article should have a different URI from the HTML form. I do think
content negotiation would be OK for things like deciding between GIF
and PNF for an image, i.e., for forms of content that are
"commodities" or very substitutable.

Bill
----
Bill Venners
Editor-in-Chief
Artima Developer
http://www.artima.com

#5853

From: "Laurian Gridinoc" <laurian@...>
Date: Sat Apr 8, 2006 10:49 am
Subject: http and pi-calculus

lauriangridinoc

Hello,

Is there any formalization of HTTP in pi-calculus?

Thank you,
--
Laurian Gridinoc

Reply | Messages in this Topic (2)

#5854

From: "Sandeep Shetty" <sandeep.shetty@...>
Date: Sat Apr 8, 2006 3:22 pm
Subject: Re: Request Header vs. Query String

sandeep.shetty@...

Hey Bill,

On 4/8/06, Bill Venners <bv-svp@...> wrote:
> > Let me re-state what I meant in my first post [1]:
> > Request modifiers should not be put in the Query String because
> > request modifiers are not supposed to affect the identify of a
> > resource. When you put request modifiers in the Query String you are
> > creating new resources where you shouldn't.
> >
> I think I see. I believe I was thrown I was thrown by the word
> "creating." Basically, I think you're saying that you shouldn't
> specify data to be used for content negotiation in query parameters
> because each set of query parameters embodies a different URI, which
> implies a different resource. Whereas request headers parameterize
> the same URI, which implies the same resource. Is that correct?

More or less, except I'm not just talking about content negotiation
but about all the request-header fields (conneg, authorization, etc.).
Also, request-headers parametrize the request which can be for the
same URI. This is about moving away from the "URI as a document
identifier" definition and moving towards the "URI represents a
resource (conceptual entity)" definition which is more in line with
REST [1]. Remember, cool URIs don't change [2].

> If so, I agree with that, though I am leaning away from most content
> negotiation anyway. For usability reasons, I think an article
> translated into different languages should each have a different URI
> for each language. Likewise for usability I think the PDF form of an
> article should have a different URI from the HTML form. I do think
> content negotiation would be OK for things like deciding between GIF
> and PNF for an image, i.e., for forms of content that are
> "commodities" or very substitutable.

I know what you mean especially from an usability perspective given
the current state of affairs [3] but there is a cost involved in doing
this as you might end up fragmenting your resource space. Say one of
the articles on your website was about an "Interview with Mr. Foo Bar"
and you had two versions of it, one in English
(http://artima.com/articles/en/interview-with-foo-bar.html) and
another in French
(http://artima.com/articles/fr/interview-with-foo-bar.html). Now
suppose this article is viewed a lot by your English speaking audience
and they happen to point to it from various places on the web, you end
up undervaluing the French version which is actually the same
resource. Apart from this, request-headers give us a standard way to
parametrize the request and get to the different representations
whereas buy putting this information in the URI in a non-standard way
makes its harder to get to the other representations.

Example:

http://artima.com/articles/interview-with-foo-bar
Accept: text/html

By changing the Accept header to application/pdf like so

http://artima.com/articles/interview-with-foo-bar
Accept: application/pdf

a client can easily get to the other format. Similarly, if the French
speaking reader visits the site he is automatically (provided his
browser is setup properly) presented the french version of the
article. If this was not the case and since the French version was
undervalued (due to the lack of links pointing to it), he might have
ended up finding the English version through a search engine and then
would have to choose (using a non-standard way) the French version.

Sandeep Shetty
http://sandeep.shetty.in/

[1] http://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm#sec_6_2_1
[2] http://www.w3.org/TR/2004/REC-webarch-20041215/#URI-persistence
[3] http://sandeep.shetty.in/2006/04/browserland-http.html

#5855

From: Elias Sinderson <elias@...>
Date: Sat Apr 8, 2006 6:49 pm
Subject: Re: http and pi-calculus

elias95060

Laurian Gridinoc wrote:

> Is there any formalization of HTTP in pi-calculus?

There had better not be, otherwise my PhD dissertation is toast.  :-)

Truthfully, I think I can say that there isn't any such work out there
-- the closest thing being various SOA process calculi for web services
a la WS-*. The flexibility afforded HTTP methods through various headers
makes this sort of formulation somewhat difficult but, I believe, not
impossible. My approach essentially boils down to treating HTTP as a
coordination language, similar to those of Linda-like tuplespaces, and
then applying techniques developed within the coordination languages
community over the last 20+ years since Linda was introduced.

While not wanting to lay all my cards down on the table right now, I do
feel that I've made some progress in this area and look forward to
discussing my research with a broader community. That being said, and
since Mark already announced it on another list, I'll be presenting a
lighter version of my advancement talk this coming Thursday in Palo Alto:
<http://www.commerce.net/events/?post=/2006/04/131600.a684eceee76fc522773286a895\
bc8436.html>
If you're in the Bay Area, you might be interested in stopping by to see
what all the fuss is about.  :-)


Cheers,
Elias

Reply | Messages in this Topic (2)

#5856

From: Bill Venners <bv-svp@...>
Date: Mon Apr 10, 2006 7:48 pm
Subject: Re: Request Header vs. Query String

billvenners

Hi Sandeep,

On Apr 8, 2006, at 8:22 AM, Sandeep Shetty wrote:

>> If so, I agree with that, though I am leaning away from most content
>> negotiation anyway. For usability reasons, I think an article
>> translated into different languages should each have a different URI
>> for each language. Likewise for usability I think the PDF form of an
>> article should have a different URI from the HTML form. I do think
>> content negotiation would be OK for things like deciding between GIF
>> and PNF for an image, i.e., for forms of content that are
>> "commodities" or very substitutable.
>
> I know what you mean especially from an usability perspective given
> the current state of affairs [3] but there is a cost involved in doing
> this as you might end up fragmenting your resource space. Say one of
> the articles on your website was about an "Interview with Mr. Foo Bar"
> and you had two versions of it, one in English
> (http://artima.com/articles/en/interview-with-foo-bar.html) and
> another in French
> (http://artima.com/articles/fr/interview-with-foo-bar.html). Now
> suppose this article is viewed a lot by your English speaking audience
> and they happen to point to it from various places on the web, you end
> up undervaluing the French version which is actually the same
> resource. Apart from this, request-headers give us a standard way to
> parametrize the request and get to the different representations
> whereas buy putting this information in the URI in a non-standard way
> makes its harder to get to the other representations.
>
> Example:
>
> http://artima.com/articles/interview-with-foo-bar
> Accept: text/html
>
> By changing the Accept header to application/pdf like so
>
> http://artima.com/articles/interview-with-foo-bar
> Accept: application/pdf
>
> a client can easily get to the other format. Similarly, if the French
> speaking reader visits the site he is automatically (provided his
> browser is setup properly) presented the french version of the
> article. If this was not the case and since the French version was
> undervalued (due to the lack of links pointing to it), he might have
> ended up finding the English version through a search engine and then
> would have to choose (using a non-standard way) the French version.
>
> [1] http://www.ics.uci.edu/~fielding/pubs/dissertation/
> evaluation.htm#sec_6_2_1
> [2] http://www.w3.org/TR/2004/REC-webarch-20041215/#URI-persistence
> [3] http://sandeep.shetty.in/2006/04/browserland-http.html
>
What you describe sound to me like the approach envisioned by the
HTTP designers when they designed content negotiation, and in Roy
Fielding's dissertation when he discusses REST. I would contest your
statement, "a client can easily get to the other format," and suggest
that is the main usability problem with content negotiation as
envisioned in the HTTP spec and REST.

In both examples you give, I believe users want to be able to chose
between representations. Most users don't understand request headers,
or how to set their preferences. With a bit of looking around, I
found how to do it in my main browser, Firefox on the Mac. So being a
somewhat sophisticated surfer, I could set my preference for French
ahead of English.

Now imagine I click on your [1] footnote to see a section of Roy
Fielding's dissertation, and being true to itself, it sends back a
French translation of that chapter of his dissertation. Well, even
though I normally prefer French while surfing, in this case, imagine
I'm doing research for a paper of my own I'm writing and I really
want the English version, because that's the authoritative version:
the version of record. To get it, I would need to go to my browser
settings and move English above French, then click reload. Then go
back to my preferences to move French back on top, which is what I
prefer most of the time. The problem is that most users will have no
idea how to solve that problem, and for those sophisticated users who
do, it is a pain.

What I'm planning to do at Artima is send back the English version,
but with a prominent link to the French version. If you really prefer
the French version, it is one click away. So I do content negotiation
in that when I notice the user prefers French over English, and they
have requested an English article for which there is a French
translation, I send them a representation of the English article that
includes a prominent link to the French translation. This allows the
user to indicate his or her preference with a mouse click rather than
going in and editing preferences, which is more user-friendly.

The situation with HTML and PDF representations of an article, which
you also described, is similar. Although je ne parle pas Francais, I
do use both PDF and HTML, so I can use myself as an example user. I
prefer HTML for on screen reading, but PDF for printing. For longer
written works--article length and longer--I prefer to print and read
on paper. I have printed Roy Fielding's thesis out, for example. I
would have preferred to actually get a PDF version of that thesis for
printing, but I didn't see one. Since I prefer HTML most of the time,
for me to get the PDF version I suppose I'd have to go change my
preferences and put PDF ahead of HTML (except I don't see any way to
do that in Firefox.) But that preference change would be just for his
thesis, and only if I happen to be interested in printing it. When
following one of your footnotes to Roy's dissertation from an email,
for example, I actually just prefer the HTML version because I want
to read a few paragraphs on screen. Even if I want to read a whole
chapter, I only want the PDF if I'm near a printer and have enough
ink and paper. So at Artima, my plan is to show the HTML version of
an article, and include a link on it to a PDF version.

The problem with the envisioned HTTP/RESTful approach to content
negotiation is that different human language representations of an
article such as French/English, and file format differences such as
HTML/PDF, are not information commodities to users. You can't just
replace one with the other. It does matter to the user which one you
give them, and what they want depends on the situation. The server
needs to negotiate with the *user*, not the user agent, to figure out
what representation they want in each specific situation. For non-
commodities, I believe the best way to do that is to give them a
different URI for each, because then the user can express his or her
wishes with a click.

Some things that I can imagine doing as-envisioned content
negotiation on are things that really are information commodities
from the perspective of the user, such as PNG and GIF. Either one you
send should provide the user with the same experience, and the user
probably doesn't care which one the browser uses to construct the
image it displays. So here it seems fine to me to do content
negotiation as envisioned by HTTP. Note that in this case, what you
are really negotiating with is the user agent, not the user.

One place I'm not sure which way to go is with a version of a URI fit
for small screens, such as Blackberries. I could just adjust the page
when I guess from the request that they are on a small screen, or I
could include a link to a small screen version. But that would really
mean there's two different sets of pages, one for desktop computers
and laptops, and one for mobile devices. I haven't figured out what
to do in this case, but I think that allowing access from mobile
devices will be important, and suspect that just sending the same
thing to big and small screens won't make users happy. I welcome
suggestions.

Bill
----
Bill Venners
Editor-in-Chief
Artima Developer
http://www.artima.com

#5857

From: Roy T. Fielding <fielding@...>
Date: Mon Apr 10, 2006 8:56 pm
Subject: Re: Request Header vs. Query String

roy_fielding

On Apr 10, 2006, at 12:48 PM, Bill Venners wrote:
> On Apr 8, 2006, at 8:22 AM, Sandeep Shetty wrote:
>
>>> If so, I agree with that, though I am leaning away from most content
>>> negotiation anyway. For usability reasons, I think an article
>>> translated into different languages should each have a different URI
>>> for each language. Likewise for usability I think the PDF form of an
>>> article should have a different URI from the HTML form. I do think
>>> content negotiation would be OK for things like deciding between GIF
>>> and PNF for an image, i.e., for forms of content that are
>>> "commodities" or very substitutable.
>>
>> I know what you mean especially from an usability perspective given
>> the current state of affairs [3] but there is a cost involved in
>> doing
>> this as you might end up fragmenting your resource space. Say one of
>> the articles on your website was about an "Interview with Mr. Foo
>> Bar"
>> and you had two versions of it, one in English
>> (http://artima.com/articles/en/interview-with-foo-bar.html) and
>> another in French
>> (http://artima.com/articles/fr/interview-with-foo-bar.html). Now
>> suppose this article is viewed a lot by your English speaking
>> audience
>> and they happen to point to it from various places on the web, you
>> end
>> up undervaluing the French version which is actually the same
>> resource. Apart from this, request-headers give us a standard way to
>> parametrize the request and get to the different representations
>> whereas buy putting this information in the URI in a non-standard way
>> makes its harder to get to the other representations.
>>
>> Example:
>>
>> http://artima.com/articles/interview-with-foo-bar
>> Accept: text/html
>>
>> By changing the Accept header to application/pdf like so
>>
>> http://artima.com/articles/interview-with-foo-bar
>> Accept: application/pdf
>>
>> a client can easily get to the other format. Similarly, if the French
>> speaking reader visits the site he is automatically (provided his
>> browser is setup properly) presented the french version of the
>> article. If this was not the case and since the French version was
>> undervalued (due to the lack of links pointing to it), he might have
>> ended up finding the English version through a search engine and then
>> would have to choose (using a non-standard way) the French version.
>>
>> [1] http://www.ics.uci.edu/~fielding/pubs/dissertation/
>> evaluation.htm#sec_6_2_1
>> [2] http://www.w3.org/TR/2004/REC-webarch-20041215/#URI-persistence
>> [3] http://sandeep.shetty.in/2006/04/browserland-http.html
>>
> What you describe sound to me like the approach envisioned by the
> HTTP designers when they designed content negotiation, and in Roy
> Fielding's dissertation when he discusses REST. I would contest your
> statement, "a client can easily get to the other format," and suggest
> that is the main usability problem with content negotiation as
> envisioned in the HTTP spec and REST.

Whoa, I think this is a case of reading too much into my dissertation.
The sites that I produce *always* separate languages into separate
URI trees.  Day Software's Communiqu� product specializes in
multilingual
sites and defaults to separate trees. E.g., if you follow a link to

     http://www.day.com/

then the site will redirect according to the user's preference to one of

     http://www.day.com/site/en/index.html
     http://www.day.com/site/de/index.html

and those pages, in turn, link to all three.  We are a Swiss company and
experts at multilingual sites.

In general, I avoid content negotiation without redirects like the
plague because of its effect on caching.

Now, section 6.2.1 does not say that content negotiation should be
used all the time.  It says

     The definition of resource in REST is based on a simple premise:
     identifiers should change as infrequently as possible. Because
     the Web uses embedded identifiers rather than link servers, authors
     need an identifier that closely matches the semantics they intend by
     a hypermedia reference, allowing the reference to remain static even
     though the result of accessing that reference may change over time.
     REST accomplishes this by defining a resource to be the semantics of
     what the author intends to identify, rather than the value
corresponding
     to those semantics at the time the reference is created. It is then
     left to the author to ensure that the identifier chosen for a
     reference does indeed identify the intended semantics.

In practice, multilingual sites rarely place equivalent content in
multiple languages on negotiated URIs without an explicit redirect.
Aside from the fact that Accept-Charset is rarely configured properly,
the fact is that different languages do not produce equivalents.
There are hundreds of nuances, colloquialisms, and shared social
norms that simply do not translate.  We encourage resource owners
to only use true content negotiation (without redirects) when the
only difference between formats is mechanical in nature.

> The situation with HTML and PDF representations of an article, which
> you also described, is similar. Although je ne parle pas Francais, I
> do use both PDF and HTML, so I can use myself as an example user. I
> prefer HTML for on screen reading, but PDF for printing. For longer
> written works--article length and longer--I prefer to print and read
> on paper. I have printed Roy Fielding's thesis out, for example. I
> would have preferred to actually get a PDF version of that thesis for
> printing, but I didn't see one.

Huh, that is getting to be a FAQ.  I have no idea why people can't see
the second and third link on the top page

     http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

that point to the two PDF editions.  *shrug*

> Some things that I can imagine doing as-envisioned content
> negotiation on are things that really are information commodities
> from the perspective of the user, such as PNG and GIF. Either one you
> send should provide the user with the same experience, and the user
> probably doesn't care which one the browser uses to construct the
> image it displays. So here it seems fine to me to do content
> negotiation as envisioned by HTTP. Note that in this case, what you
> are really negotiating with is the user agent, not the user.
>
> One place I'm not sure which way to go is with a version of a URI fit
> for small screens, such as Blackberries. I could just adjust the page
> when I guess from the request that they are on a small screen, or I
> could include a link to a small screen version. But that would really
> mean there's two different sets of pages, one for desktop computers
> and laptops, and one for mobile devices. I haven't figured out what
> to do in this case, but I think that allowing access from mobile
> devices will be important, and suspect that just sending the same
> thing to big and small screens won't make users happy. I welcome
> suggestions.

Mobile devices usually have a different set of interesting
transitions (links), different artwork, and often different content.
I usually treat them the same way as different languages.  Note that,
like the home page above, the "cool URI" entry points that get
published on other sites/email/papers are all negotiated, but result
in a redirect to the language+device view of preference.

....Roy

#5858

From: Yannick Loiseau <yloiseau@...>
Date: Tue Apr 11, 2006 7:15 am
Subject: Re: Request Header vs. Query String

pioupiougroups

Bill Venners wrote:

> The problem with the envisioned HTTP/RESTful approach to content
> negotiation is that different human language representations of an
> article such as French/English, and file format differences such as
> HTML/PDF, are not information commodities to users. You can't just
> replace one with the other. It does matter to the user which one you
> give them, and what they want depends on the situation. The server
> needs to negotiate with the *user*, not the user agent, to figure out
> what representation they want in each specific situation. For non-
> commodities, I believe the best way to do that is to give them a
> different URI for each, because then the user can express his or her
> wishes with a click.

I think all the issue here is mainly due to browser limitations, as they
doesn't allow the user to easily swith conneg preferences. The more I
read discussions or I am involved in service design, the more I think
about making a Firefox extention displaying some info about the
available conneg on the page (Accept / Vary header ?) and providing some
menu of field to change settings for the current page only. Some
extentions already display Header fields, but I'm not aware of a
"switcher" extention, except the ones allowing to fully customize
header, which is not so user friendly.

An other approach to your PDF problem could be the browser set
automaticaly the Accept header to "application/postscript,
application/pdf, text/html;q=0.8,text/*;q=0.5;*/*;q=0.1" and reGET the
page when clicking on "print".

For the "send link" and bookmark issue, you can always send a redirect
based on conneg, if each version has is own uri.

#5859

From: "manoj" <manojjain_mca1981@...>
Date: Tue Apr 11, 2006 6:12 am
Subject: Getting problem in use REST in development of webservice

manojjain_mc...

Hi all Friends..
  I m beginner of webservice. i have made a web service in asp.net and
after then i have add that one with a client by using  add webreference,
So i want to know that is working through SOAP or REST.I have study
more about REST Vs SOAP, then i got REST better then SOAP in many
Perspective so i want to use REST in my webservice.
so plz tell me how to use REST in webservice,i want to whole procedure.
if i will get a example that is better for me to understand..
Waiting for help....

Thanks

Reply | Messages in this Topic (24)

#5860

From: Nic <nferrier@...>
Date: Tue Apr 11, 2006 12:53 pm
Subject: Re: Getting problem in use REST in development of webservice

nferrier_tap...

"manoj" <manojjain_mca1981@...> writes:

> Hi all Friends..
>  I m beginner of webservice. i have made a web service in asp.net and
> after then i have add that one with a client by using  add webreference,
> So i want to know that is working through SOAP or REST.I have study
> more about REST Vs SOAP, then i got REST better then SOAP in many
> Perspective so i want to use REST in my webservice.
> so plz tell me how to use REST in webservice,i want to whole procedure.
> if i will get a example that is better for me to understand..
> Waiting for help....

To make a REST webservice simply build a normal webapp with different
resources.

Restrict yourself to the HTTP methods as the verbs for your
webservice, eg:

  GET     get the resource
  POST    create a new resource
  PUT     edit the resource
  DELETE  move the resource
  HEAD    brief overview of the resource


There are quite a few tutorials for build REST apps. You can find them
by searching on Google.


Nic Ferrier

Reply | Messages in this Topic (24)

#5861

From: Bill Venners <bv-svp@...>
Date: Tue Apr 11, 2006 3:53 pm
Subject: Re: Request Header vs. Query String

billvenners

Bonjour Yannick,

On Apr 11, 2006, at 12:15 AM, Yannick Loiseau wrote:
>> The problem with the envisioned HTTP/RESTful approach to content
>> negotiation is that different human language representations of an
>> article such as French/English, and file format differences such as
>> HTML/PDF, are not information commodities to users. You can't just
>> replace one with the other. It does matter to the user which one you
>> give them, and what they want depends on the situation. The server
>> needs to negotiate with the *user*, not the user agent, to figure out
>> what representation they want in each specific situation. For non-
>> commodities, I believe the best way to do that is to give them a
>> different URI for each, because then the user can express his or her
>> wishes with a click.
>
> I think all the issue here is mainly due to browser limitations, as
> they
> doesn't allow the user to easily swith conneg preferences. The more I
> read discussions or I am involved in service design, the more I think
> about making a Firefox extention displaying some info about the
> available conneg on the page (Accept / Vary header ?) and providing
> some
> menu of field to change settings for the current page only. Some
> extentions already display Header fields, but I'm not aware of a
> "switcher" extention, except the ones allowing to fully customize
> header, which is not so user friendly.
>
Well, we'd have to do user testing with the actual implementation of
your idea. But I can't imagine anything simpler for the user than
point and click.

> An other approach to your PDF problem could be the browser set
> automaticaly the Accept header to "application/postscript,
> application/pdf, text/html;q=0.8,text/*;q=0.5;*/*;q=0.1" and reGET the
> page when clicking on "print".
>
Well, the trouble with this is that not every user is like me. I like
to print PDF and read HTML on screen, but does everyone? And I don't
*always* want to print PDF. Right now in my backpack I have a few
chapters of Roy's thesis printed out, chapters 5 and 6 I think,
because those were of greatest interest to me. At the time of
printing, I didn't want to pay for paper and ink for the others, or
carry around the weight and bulk. And in that situation it is
actually easier for me to print the two HTML documents for those two
chapters, and go into the PDF and figure out which from and to page I
want. Having a different URI for each chapter was exactly what I
wanted, and exactly what I was given.

> For the "send link" and bookmark issue, you can always send a redirect
> based on conneg, if each version has is own uri.
>
This is true, but I think people will tend to send the URL that's in
the address bar of the browser, not the one that's listed somewhere
as the canonical URL for the content. People will most likely link to
one of the non-entry URLs. Hmm. I think I need some terminology. How
about "entry URI" for the one that uses conneg to redirect to another
"target URI". My untested belief is that people will most likely send
in emails the target URI they land on, and put links in their web
pages using those target URIs. So search engines will favor the
target URIs, not the entry URI. Therefore, people will rarely go to
an entry URI. I don't have any plans for using entry URIs. Instead,
there are just "target URIs," but the target URIs will use conneg to
decide whether to point to each other prominently. The one place
where I think an entry URI might work is the example that Roy gave in
his earlier email on this thread, which is to the domain home itself,
as in:

http://www.day.com/

People will type that in and go there, and that URL does seem to get
indexed by search engines. Otherwise, I'm not sure that the entry URI
approach is very useful. Has anyone had success with this other than
on the domain home URL?

Bill
----
Bill Venners
Editor-in-Chief
Artima Developer
http://www.artima.com