RE: Ideas: GETSRC & MULTIPUT

Roy,

> That would, of course, be completely contrary to the HTTP design and
> further propagate the mistake of not accessing properties as resources.
> Just use the source link.

The source link didn't work. Telling people to use the source link is not,
IMO, productive.

GETSRC could be defined as something like, "returns to the client a
representation of the resource suitable for editing in an authoring client",
so we avoid issues of getting at the "true" state of the resource. GETSRC
wouldn't have the same caching properties as GET; I don't see that as being
a big problem for authoring.

So, which specific HTTP design principle(s) does this proposal violate?

> > The second is to introduce the MULTIPUT method to support "PUT with
> > PROPPATCH" scenarios. MULTIPUT would accept some subset of
> multipart MIME
> > packages and atomically write them to the server. This would support the
> > update of a resource and its metadata in one transaction.
>
> Please choose a better name -- MPUT and MULTIPUT means multiple
> PUT requests, which was already tried and abandoned.  Maybe you can call
it
> PKG.  Or just define a mapping to transactions and leave them as separate
> requests.

I don't want to do arbitrary transactions, since that dramatically increases
the implementation burden. But I'd be happy to call it something different.

- Jim

Received on Monday, 29 October 2001 19:07:39 UTC