RE: Locking a Resource or Locking a URL?

In a message he's probably forgotten, on March 9, Roy Fielding wrote:
> That's pretty much what I meant.  Let's say we have three URI --
> A, B, C --
> which have the following relationship
>
>      A is any resource
>      B is a direct reference resource whose target is A
>      C is a resource that defines the mapping B --> A
>
> C is therefore a resource that generates side-effects on other resources,
> a common thing in HTTP.  The above is, in fact, how most servers are
> configured today, though few allow remote editing of the config file C.

*snip* (the full message can be found at:
http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0230.html)

The authoring team for Advanced Collections has debated this approach, and
decided not to adopt it for the following reasons:

1) It would require an extra discovery step to determine where the
authorable namespace mapping resource is found.  So, instead of being able
to directly say "create binding at B to A" by issuing a method directly to
URL B, first a client would need to query a property (most likely on its
containing collection) to discover the authoring location, then go modify
the authoring location.

2) It would either require extra methods to specifically modify the
authorable mapping resource (ADD_MAPPING, REMOVE_MAPPING, with the
consequence of introducing a new type of resource, the mapping resource), or
it would require the client to understand the syntax (and require the
protocol to standardize the syntax) of the mapping resource (but at least it
would be a plain, generic resource).  This would introduce the problem of
how to handle MOVEs on this resource.  It would also confuse the definition
of a collection, since the binding between a URL and a resource would belong
to more than one resource (the collection and the mapping resource).

- Jim

Received on Monday, 19 April 1999 19:51:02 UTC