Hi,

HTTP defines the semantics of POST (roughly speaking) as 'add to collection' and
'process
this', the latter being the case where the POSTed data is only processed and no
resource is
created.

I have just come to think that the Atom Publishing Protocol[1] not only uses
HTTP but also
constrains it further by excluding the 'process this' semantic of POST (at least
when
interacting with an APP collection). Resource creation upon POST is mandatory
for an APP
collection.

When designing a system using HTTP *and* APP (meaning: assuming them both to be
pervasive) this has an (IMO) interesting effect on the options you have when
designing how
to 'get stuff done'. If I want to launch a rocket for example, I can only do
this through
manipulation of resource state and not through having a
rocket-launcher-processor
process some rocket-launch-control data. I either need to set the state of a
given rocket-
resource to 'launch' or I need to ceate a rocket-resource, maybe with some
appropriate
control data (which is IMHO equivalent to intended-resource-state-after-creation
- see
app:draft[2][).

Actually, I wonder if actions that are performed through 'process this'-POST
(and not
through manipulation of resuorce state) aren't in fact hidden RPC anyhow and
thus are
against REST's architectural principles. In which case APP would rather be
setting matters
straight as opposed to adding an additional constraint.

Practically, I think that having less design options for how to get an action
done in a
system helps people understand how to approch systems design with REST.

Now, if that does make any sense at all, I'd be very interested in comments on
this.

Jan



[1] http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-11.html
[2] http://bitworking.org/projects/atom/draft-ietf-atompub-
protocol-11.html#rfc.section.12.1.1