[go: up one dir, main page]

Re: [putMediaType-38] reopening discussion

Roy,

I like this analysis a lot.  I'd also like to suggest that to properly 
generalize, we should think about dynamic as well as static resources.   I 
think that doing so makes the case that your option #3 is less tricky than 
it appears, particularly in the dynamic case where we are creating 
resources that change over time.

Let's say that I am the owner of a set of clock resources.  I control the 
example.org/clocks domain, and I make known to the world that a "PUT" for 
media type text/plain to any URI in that hierarchical space will in fact 
cause creation of a clock resource.  The initial time will be set based on 
the time conveyed in the message, and from there on the clock will 
advance.  I document that subsequent GETs will, for whatever reason, 
return an image/jpeg of the clock face, showing what the server believes 
to be the then-current value per that clock.  I might do this because 
text/plain is just one of the formats I use for setting the clocks, but in 
all cases they return images. So I create and set a clock with:

    PUT /clocks/noahclock.txt HTTP/1.1
    Host: example.org
    Content-type: text/plain

>From the outside, this looks exactly like your example, and I think fits 
with your option #3, I.e. the returned representation need not be of the 
same type is the originally supplied, provided that everyone involved 
agrees.  I suppose I'm bolstering the case that option #3 is important. 
I'm claiming that it looks less odd in the case where you already know 
that HTTP is not being used as a filesystem, because the resources are 
dynamic.

Perhaps it's worth explicitly going into examples like this?  I'm curious, 
do you believe that good practice is at all affected by the static/dynamic 
nature of the resource?   Indeed, do we want to get into the business of 
suggesting that the media type used to set a clock should be taken as a 
hint regarding the media type with which it will respond?  I would think 
not. 

So, my overall point is that the "static resource" case is ultimately a 
special case, though extremely common.  Furthermore, we can't really know, 
whether your something.html is really a static resource, unless we 
architect that as a distinct subclass on the Web.  Unless we have out of 
band information, such as a statement from the resource owner that the 
resource is static, we can only tell that it hasn't changed up to any 
given point where we check.   Perhaps the "PUT" was to a CVS-like 
repository, and edits or changes of media type will occur over time.

You wrote:

> My inclination is that (1) is a bug, (2) is bad
> implementation, (3) is a nifty feature when the
> user is making an informed request, and (4) is the
> right answer in all other cases.

Exactly.  I'm suggesting that dynamic resources are an interesting special 
case of an "informed request", presuming the user knows he/she issetting a 
clock and not writing a time into a filesystem.  The fact that you know 
that the underlying state is going to change seems to me to affect your 
default expectation of anything resembling filesystem semantics.  It may 
put some addition nuance on the suggestion that "(4) is the right answer 
in all other cases."

As I say, overall I'm in complete agreement with your analysis and 
conclusions.  Just suggesting that perhaps that discussion of dynamic 
resources might be valuable in framing the general-case behavior of HTTP, 
with static resources (filesystem semantics) presented as a common special 
case.  Your call:  you don't have to further convince me one way or the 
other.  Thanks.

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

Received on Tuesday, 3 May 2005 14:04:12 UTC