Making kio_http more accessible to RESTful clients

[Josef Spillner]

Am Montag, 6. Oktober 2008 08:12:35 schrieb Thiago Macieira:
> SOAP's HTTP transport is always POST. But that's just the transport: even
> for obtaining data it uses POST.

Wrong. Please consult part 2 of the specification where it clearly mandates 
the implementation of both POST and GET. But in the context of this 
discussion, it doesn't matter. What matters is that SOAP operations process 
data instead of working on locatable resources.

> I would argue that SMTP sending (even according to your description) is
> "put", not "post". It sends something and maybe it'll give you a
> confirmation and an identification. That's all.

The semantics of PUT is that a resource is stored and can be retrieved from 
the same location (barring a 301-PUT where it can be retrieved from another 
location).

The semantics of POST is that some processing is done with the data, not 
necessarily that it is stored. A 204-POST processes without giving feedback 
other than a confirmation. Exactly what you described above, hence SMTP 
follows POST semantics and not PUT semantics (especially since essentially all 
MTAs modify messages by design, adding Received headers and whatnot).

> HTTP's POST is a special kind of operation that both uploads data and then
> downloads it. It's not something you'll easily find in other protocols.
> That's why it's "http_post" in KIO.

POST semantics doesn't imply "downloading data". The result might refer to a 
newly created resource, but it doesn't have to. Please read section 9.5 of the 
relevant specification.

At an abstract level, to avoid confusion, my suggestion is to use a naming 
which reflects the difference of storing vs. processing. That is all.

Josef