[uf-rest] Roy Fielding on WebDAV and PROPs

Dan Kubb dan.kubb at autopilotmarketing.com
Tue Apr 11 15:56:28 PDT 2006


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Ernie,

> The interesting question for me is what the "right" way to do  
> properties would be over HTTP.  I presume it would require some  
> sort of convention for a property namespace, which implies non- 
> opaque URLs.  Which in term (in order to be RESTful) would require  
> the *server* to have some way to tell clients about it, since  
> clients shouldn't *assume* URI structure.
>
> Any thoughts about the optimal way to do that?

I was thinking that the Link header from RFC 2068 would be a good
fit for this.  There's a note at the end of RFC 2616 that it was
obsoleted because it wasn't widely implemented.

Here's the relevant section from RFC 2068 on the Link header:

> 19.6.2.4 Link
>
>    The Link entity-header field provides a means for describing a
>    relationship between two resources, generally between the requested
>    resource and some other resource. An entity MAY include multiple  
> Link
>    values. Links at the metainformation level typically indicate
>    relationships like hierarchical structure and navigation paths. The
>    Link field is semantically equivalent to the <LINK> element in
>    HTML.[5]
>
>           Link           = "Link" ":" #("<" URI ">" *( ";" link- 
> param )
>
>           link-param     = ( ( "rel" "=" relationship )
>                              | ( "rev" "=" relationship )
>                              | ( "title" "=" quoted-string )
>                              | ( "anchor" "=" <"> URI <"> )
>                              | ( link-extension ) )
>
>           link-extension = token [ "=" ( token | quoted-string ) ]
>
>           relationship   = sgml-name
>                          | ( <"> sgml-name *( SP sgml-name) <"> )
>
>           sgml-name      = ALPHA *( ALPHA | DIGIT | "." | "-" )
>
>    Relationship values are case-insensitive and MAY be extended within
>    the constraints of the sgml-name syntax. The title parameter MAY be
>    used to label the destination of a link such that it can be used as
>    identification within a human-readable menu. The anchor  
> parameter MAY
>    be used to indicate a source anchor other than the entire current
>    resource, such as a fragment of this resource or a third resource.
>
>    Examples of usage include:
>
>        Link: <http://www.cern.ch/TheBook/chapter2>; rel="Previous"
>
>        Link: <mailto:timbl at w3.org>; rev="Made"; title="Tim Berners- 
> Lee"
>
>    The first example indicates that chapter2 is previous to this
>    resource in a logical navigation path. The second indicates that  
> the
>    person responsible for making the resource available is  
> identified by
>    the given e-mail address.

- --

Thanks,

Dan
__________________________________________________________________

Dan Kubb
Autopilot Marketing Inc.

Email: dan.kubb at autopilotmarketing.com
Phone: 1 (604) 820-0212
Web:   http://autopilotmarketing.com/
vCard: http://autopilotmarketing.com/~dan.kubb/vcard
__________________________________________________________________



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)

iD8DBQFEPDQc4DfZD7OEWk0RAnQ+AJwJ5mpHwntpzjEVUd7DBjkaJ+cJXwCeMf4W
syVdupd32GsiX0x0wNtZQ+8=
=/56x
-----END PGP SIGNATURE-----


More information about the microformats-rest mailing list