Re: POST vs. separate methods

This kind of philosophizing is fun, but I think that the HTTP
framework for 'POST' really does allow a fairly wide range of semantic
options based on the content (not the content-type, but the content)
of the message.

On a different discussion group, I was asked how to implement
printing using HTTP, and in particular the operations

#    SubmitJob
#    CancelJob
#    ListJobAttributes
#    ModifyJob
#    ResubmitJob

I suggested:

# SubmitJob could easily be a POST which returns a job attributes and a
# Location: header that is the Job URL. CancelJob could be done with a
# DELETE of the Job URL, ListJobAttributes might be GET of the Job URL,
# ModifyJob could be a PUT of the Job URL with a new set of Job
# Attributes (or Post). I don't know what ResubmitJob might be, but
# perhaps it's a POST too.

Now, just so we don't think we've gone too far from 'distributed
authoring and versioning', remember that 'distributed authoring' blurs
into 'workflow' pretty easily, so that each document uploaded might in
fact be accompanied by some processing instructions, and that the
processing instructions might be considered the metadata. In fact,
many applications of 'distributed authoring' do exactly that:
transaction semantics on document metadata allow a complete workflow
system to be built.

So, is it in the spirit of HTTP to add a SUBMIT method, or is POST of
the job instructions to the job recipient URL good enough?

Larry

Received on Wednesday, 6 November 1996 04:18:17 UTC