RE: Vocabulary for HTTP headers

Richard Smith [mailto:richard@ex-parrot.com] wrote:
> Tore Eriksson wrote:
> 
> > Allow me to point out that Content-Type and Content-Length are meta
> > data not describing the resource, but the entity body/representation
> > (httpRange-14 and all that). For an internal application conflating
> > these into one compound resource is one way of modelling, but in my
> > experience keeping them separate makes things clearer in the end.
> 
> The two places I can see this causing a problem are:
> 
> 1) A URI, <foo>, might be the identifier for some physical resource, such
> as a painting, but dereferencing <foo> might give a document of some sort,
> and therefore have a Content-Type, which is not anything to do with the
> painting.
> 
> 2) A URI, <foo>, might be an electronic resource, such as a photo, but the
> entity you get by dereferencing <foo> might vary because of, say, HTTP content
> negotiation.  Therefore <foo> might have different Content-Types depending
> on context.

Both cases are plausible, but my point is that the most common problem is:

3) The state of the resource changes over time (someone edits the document) and
this causes the entity (the representation) describing the state of the object
to change, and the HTTP headers (Content-Length, ETag) change accordingly.

You can model this as 
A) <foo> with multiple changing properties, or as
B) <foo> having changing representations with fixed properties

In your case you apparently only have to deal with electronic resources with no
content negotiation, and in this case both A) and B) are possible solutions.
I used to do A) in my own projects but switched to B) because it made my code
simpler.

However, the neat thing with B) is that it also covers 1) and 2) as well, meaning that
httpRange-14 becomes a non-issue. Paintings don't end up with Content-Lengths and
photos can have both RAW and jpeg representations.

Tore

Received on Thursday, 13 February 2014 01:22:05 UTC