Re: Proposed issue; Visibility of Web services

+1

I was drafting a near identical response when my mail client crashed. POST
means whatever the origin server wants it to mean in the context of the 
resource's
URI. Hence, no set semantic can be assigned. It might as well have been 
called
DOSOMETHINGWITHTHEENTITYBODYINTHEREQUEST:)

So, back to Noah's original response, XMLP added the Web method to SOAP, 
they gave
specific recommendations that it should be used. Isn't that enough.

The method is only the tip of the visibility iceberg. I think that it is 
more critical to 
have visibility of the headers. There's an abundance of "visibility" of 
the RFC2616
defined HTTP header fields, but the extension headers? No "visibility" 
there I'm afraid:

        "The extension-header mechanism allows additional entity-header 
fields
         to be defined without changing the protocol, but these fields 
cannot
        be assumed to be recognizable by the recipient. Unrecognized 
header
        fields SHOULD be ignored by the recipient and MUST be forwarded by
        transparent proxies."

I would actually go as far as to suggest that SOAP is MORE visible than 
HTTP
because a) there is a well defined process model and b) you don't have to 
concern
yourself of having name collision because SOAP headers are namespace 
qualified. An intermediary can be more certain that it will (correctly) 
understand SOAP headers
(semantic, not syntactic, understanding) than it can HTTP headers because 
there is 
always the possibility that HTTP headers that are not defined in RFC2616 
might be 
misconstrued due to name collision. In fact, an intermediary can know if 
the header is 
important or can be safely ignored. 

SOAP *can* be used in a RESTful manner, and the XMLP WG has taken great 
pains
to ensure that to be the case. The fact of the matter is that you are 
setting the bar higher for
Web services than for HTTP itself. There is lots you can do with HTTP that 
is not very RESTFUL.
Should we be falling all over ourselves and raising issues with the TAG to 
protect the Web from 
HTTP!? Not likely.

You keep claiming that it is only the constraints of REST, manifested in 
the HTTP protocol, 
which have allowed the Web to flourish. I think that experience has 
actually proven such a claim to be 
somewhat exaggerated. People have used and abused the Web in many 
nonRESTful ways and 
yet the Web has flourished despite such abuses. 

I certainly believe that there is MUCH to be said for REST and its 
architectural constraints, just as I am 
sure that those constraints have in some way helped the Web to flourish. 
However, I also firmly believe 
that the application of the Web, a hyperlinked information space 
(typically, but not exclusively, accessed
via a browser) is not an application that necessarily maps easily or 
readily to all other (many, pre-existing
and not usually subject to modification (if it ain't broke...)) 
applications. You will no doubtedly claim
otherwise as is your prerogative, but it is yet another unsubstantiated 
claim.

There is nothing stopping you, or anyone else from using SOAP (and WSDL)
such that there are only a few well defined methods, possibly ripped right 
out of RFC2616 (but with
a couple of others added in because even you agree that there are new 
methods worth adding
(MONITOR/WATCH). Here, I'll even write the WSDL.

<definitions xmlns="http://schemas.xmlsoap.org/wsdl/" 
        targetNamesapce="http://markbaker.com" 
        xmlns:tns="http://markbaker.com"
        xmlns:my="http://markbaker.com/schema"
        name="myuberservicedescription"
        xmlns:xs="http://www.w3.org/2001/XMLSchema"
        xmlns:s="http://schemas.xmlsoap.org/wsdl/soap/">
  <types>
    <schema xmlns="http://www.w3.org/2001/XMLSchema" 
        targetNamespace="http://markbaker.com/schema" 
        xmlns:tns="http://markbaker.com/schema"
        xmlns:xs="http://www,w3.org/2001/XMLSchema">
      <element name="uri" type="xs:anyURI"/>
      <element name="message">
        <complexType>
          <sequence>
            <element ref="tns:uri"/>
            <any namespace="##other" processContents="skip" minOccurs="0" 
maxOccurs="unbounded"/>
          </sequence>
          <anyAttribute namespace="##other" processContents="skip"/>
        </complexType>
      </element>
      <element name="faultDetails">
        <complexType>
          <sequence>
            <element name="code">
              <simpleType>
                <simpleContent>
                  <restriction base="xs:string">
                    <enumeration value="1xx"/>
                    <enumeration value="2xx"/>
                    <enumeration value="3xx"/>
                    <enumeration value="4xx"/>
                    <enumeration value="5xx"/>
                  </restriction>
                </simpleContent>
              </simpleType>
            </element>
            <any namespace="##other" processContents="skip" minOccurs="0" 
maxOccurs="unbounded"/>
          </sequence>
          <anyAttribute namespace="##other" processContents="skip"/>
        </complexType>
      </element>
    </schema>
  </types>
  <message "justauri">
    <part name="x" element="my:uri"/>
  </message>
  <message "any">
    <part name="x" element="my:message"/>
  </message>
  <message "anyFault">
    <part name="fault" element="my:faultDetail"/>
  </message>
  <portType name="uberalles">
    <operation name="GET">
      <input message="my:justauri"/>
      <output message="my:message"/>
      <fault message="my:anyFault"/>
    </operation>
    <operation name="PUT">
      <input message="my:message"/>
      <output message="my:message"/>
      <fault message="my:anyFault"/>
    </operation>
    <operation name="DOSOMETHINGWITHTHEENTITYBODYINTHEREQUEST">
      <input message="my:message"/>
      <output message="my:message"/>
      <fault message="my:anyFault"/>
    </operation>
    <operation name="DELETE">
      <input message="my:justauri"/>
      <output message="my:message"/>
      <fault message="my:anyFault"/>
    </operation>
  </portType>
  <binding name="onlyoneneeded" type="tns:uberalles">
    <s:binding transport="http://schemas.xmlsoap.org/soap/http" 
style="document"/>
    <operation name="GET">
      <s:body use="literal"/>
    </operation>
    <operation name="PUT">
      <s:body use="literal"/>
    </operation>
    <operation name="DOSOMETHINGWITHTHEENTITYBODYINTHEREQUEST">
      <s:body use="literal"/>
    </operation>
    <operation name="DELETE">
      <s:body use="literal"/>
    </operation>
  </binding>
  <service name="[yourservicenamegoeshere]">
    <port 
binding="tns:onlyoneneededbecausehttpistheperfectapplicationprotocol">
      <s:address location="[yourresourceurigoeshere]"/>
    </port>
  </service>
<definitions>

I guess we can all go home now, there's nothing more to be done.

Cheers,

Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
phone: +1 508 234 3624

www-ws-request@w3.org wrote on 05/27/2003 05:13:12 PM:

> 
> > Yes, in practice, POST is a bit of a black hole in that respect (but
> > with any data, not just binary).
> 
> Mark, you and I had this discussion almost a half a year ago
> on rest-discuss.  "POST is a bit of a black hole".  If indeed it's an 
> elongated black hole, then that makes it a tunnel.  It would be hard
> for an intermediary to determine whether any given POST
> message was
> 
>    a. Appending a database
>    b. annotating some document
>    c. submitting data for "processing"
>    d. adding to a bulletin board
> 
> That being the case, what is the meaning of your next statement
> below?  The POST action could be darned near anything, so
> what's left not to expect?
> 
> > 
> > FWIW, a RESTful use of POST is quite visible; an intermediary knows 
that
> > there is no expectation of anything happening other than the POST 
action
> > being taken (i.e. no tunneling going on).
> > 
> 
> Okay, so if the application is not tunneling beyond the tunnel
> already provided by POST, then intermediaries know the application
> is not doing a GET, and so they know not to cache the response.
> Is there anything else?
> 
> Walden
> 
>

Received on Tuesday, 27 May 2003 20:08:21 UTC