RE: Proposed issue: site metadata hook (slight variation)

> 1. Can HTTP/REST be redefined so that GET + Meta: can return something
>    other than a representation?

    I think you'd have a really hard time getting acceptance on that
one.  
    I'd still prefer to see something that made the request through the
    OPTIONS method, and since OPTIONS can take an entity body, more 
    complex requests could be defined (for getting robots info etc.)

    If conventions are to be applied, it would seem more palatable to
    apply them to the OPTIONS method since it is open for future 
    extensions.

      Request:

        OPTIONS /some-namespace-uri HTTP/1.1
        Host: whatever

      Response:

        HTTP/1.1 200 OK
	 Allows:  GET, PUT, POST
        Meta-Location: /metadata    

    The meta-meta issue isn't a problem if OPTIONS returns a
Meta-Location:
    header to another resource.  That resource could be a general
resource
    used for many types of metadata using an Accept header.

        GET /metadata HTTP/1.1
        Accept: application/rdf+xml  

    The metadata of that resource could refer back to the resource it is
    describing using another header (I like the Meta-About: header that
    Roger Costello et al have proposed) [1]

       OPTIONS /metadata HTTP/1.1
	Host: whatever

	HTTP/1.1 200 OK
       Meta-Location: /metametadata
       Meta-About: /some-namespace-uri
  
    This could also be used by 3rd party metadata providers (the point
    that Joshua Allen raised earlier and which is specifically addressed
    by Costello et al's proposal.)

> 2. Can the Meta-Location: tag be optional, if the server 
> owner does not care to name that body of knowledge explicitly?

   I would think it would have to be.  Fielding took issue with that
   header always being there in a message to rest-discuss [2].  This
   would really only be an issue if you tried to ride along with the
   GET response though; OPTIONS response wouldn't be as frequent.

> 3. Can the Meta: tag be specified with no parameter to 
> indicate a default RDF/XML encoded response?
  
    In my example above, I used an Accept header, do you think that this
    would be a better alternative?
    
> 4. Can that default RDF/XML response be, by formal definition, a 
>    concise/bounded description consisting only of statements having
>    the specified resource as subject, and recursively, for each
>    blank node object, all statements with that blank node as subject?
> 
>    [it would be *possible* to ask for and return a RDDL instance that
>     is a gross superset of or even disjunct with the body of knowledge
>     about the resource, but that would not be the default response]
>
> 5. Can the semantics of PUT and DELETE (at least) also be modified to
>    take the Meta: tag and thus allow the manipulation of knowledge
>    on the server (permissions allowing, of course)?

    If the metadata is it's own resource, this shouldn't be a problem.
Or
    am I missing something here??

[1] http://www.xfront.com/dist-reg/distributed-registry.html
[2] http://groups.yahoo.com/group/rest-discuss/message/3315

Received on Wednesday, 12 February 2003 09:12:48 UTC