Re: SOAP and the Web architecture

Hi Dick.

> 
> >POST is designed to allow a uniform method to cover the following
> functions:
> 
> >      - Annotation of existing resources;
> >
> >      - Posting a message to a bulletin board, newsgroup, mailing list,
> >        or similar group of articles;
> >
> >      - Providing a block of data, such as the result of submitting a
> >        form, to a data-handling process;
> >
> >      - Extending a database through an append operation.
> >
> >I've seen HTML forms used for all four.
> 
> Various segments of the Energy industry have standardized on HTTP POST for
> the
> reliable, secure exchange of signed/encrypted business data (X12, XML,
> etc.), following
> RFC 2388 (http://www.ietf.org/rfc/rfc2388.txt). Metadata (routing,
> identification, etc.) is represented in form elements that accompany the
> business data.
> This approach is used for both automated, unattended agent based processing
> and
> interactive browser based interactions for SME's.

For sure, but I'd classify those features as extended transfer semantics,
as would be represented by HTTP or SOAP-bound-to-HTTP headers.  For
example, I could post a message to a mailing list in a secure, routed
manner.

The functions above are intended to be the possible types of side effects
of a POST operation, independant of the QoS over which the POST arrives.

MB

Received on Saturday, 25 August 2001 10:46:57 UTC