Loading ...
Sorry, an error occurred while loading the content.
 

Proposal for SOAP GET test

Expand Messages
  • Paul Prescod
    Apologies in advance that I do not have much understanding of the soapbuilders testing process. So my terminology may be off base. Anyhow, I think that it is
    Message 1 of 5 , Jul 20 5:58 PM
      Apologies in advance that I do not have much understanding of the
      soapbuilders testing process. So my terminology may be off base.

      Anyhow, I think that it is the clear intent of both the HTTP and SOAP
      specifications that the same URI be able to respond to GET and POST
      messages. Therefore, I propose that the "main" endpoint URI for the
      standard SOAP tests be the same URI used for testing the GET method.
      That tests both that the endpoint can handle GET and that it can handle
      GET and POST on the same URI.

      I believe that the GET could return a document with metadata about the
      toolkit (I think there is already a getEndpointInfo method or
      something...this could duplicate that data). In addition, it should
      contain something like this:

      <getTests>
      <getString x:href="http://myservice.com/myendpoint/getString"/>
      <getStruct x:href="../getStruct"/>
      <getArray x:href="../SOME_RANDOMLY_GENERATED_UUID"/>
      ....
      </getTests>

      I want to emphasize that the internal structure of the URIs is opaque to
      the client being tested, but is of course meaningful to the server being
      tested. The test should imply no constraints on the structure of those
      URIs. After succeeding in doing getTests, the service should do a GET on
      getString, getStruct, getArray etc.

      As Sam has said, following these sorts of opaque address hyperlinks
      is a key part of the way GET is envisioned to
      work. One advantage of putting tests like this in the soapbuilders suite
      is that it will give a very public example of the sorts of services that
      WSDL is not currently good at describing. (Simon's demo is another
      important example)
      --
      Come discuss XML and REST web services at:
      Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
      Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
    • Rich Salz
      ... Is that important? I don t care, but I m curious. /r$
      Message 2 of 5 , Jul 20 6:36 PM
        > That tests both that the endpoint can handle GET and that it can handle
        > GET and POST on the same URI.

        Is that important? I don't care, but I'm curious.
        /r$
      • Sam Ruby
        ... I ll give you two answers. In REST terms, a URI is a Uniform Resource Identifier. In other words, it identifies a resource. The Python analog would be an
        Message 3 of 5 , Jul 20 7:47 PM
          Rich Salz wrote:

          >>That tests both that the endpoint can handle GET and that it can handle
          >>GET and POST on the same URI.
          >>
          >>
          >
          >Is that important? I don't care, but I'm curious.
          > /r$
          >

          I'll give you two answers.

          In REST terms, a URI is a Uniform Resource Identifier. In other words,
          it identifies a resource. The Python analog would be an object.
          Carrying this analogy further, a GET would be like a __str__(self):
          method, and a PUT would be like any method that may update the state of
          the object, say, __add__(self, other). If would be a rather strange
          implementation of Python that did not permit __str__ and __add__ methods
          on the same class, eh?

          In SOAPBuilders terms, I'd like to ensure that if someone were to design
          an application using Apache Axis and Java and then get disatisfied and
          want to reimplement it using ZSI and Python, that they would be free to
          do so. So, while URI's may be opaque and completely up to the server to
          generate, it is still possible to compare opaque URIs for equality, so
          this can be significant.

          - Sam Ruby
        • Rich Salz
          Okay, so it really is the same resource, so it should be the same URL. I ll buy that. Thanks. /r$
          Message 4 of 5 , Jul 20 8:31 PM
            Okay, so it really is the same resource, so it should be the same URL.
            I'll buy that. Thanks.
            /r$
          • Paul Prescod
            ... Yes, I feel it is important. Thanks to the flexibility of URIs and hypertext it may not be strictly necessary because a GET-catching resource could have a
            Message 5 of 5 , Jul 20 9:29 PM
              Rich Salz wrote:
              >
              > > That tests both that the endpoint can handle GET and that it can handle
              > > GET and POST on the same URI.
              >
              > Is that important? I don't care, but I'm curious.

              Yes, I feel it is important. Thanks to the flexibility of URIs and
              hypertext it may not be strictly necessary because a GET-catching
              resource could have a link to a POST-catching resource. But then you may
              need to unnaturally split a single logical thing into two. It's kind of
              weird to have the sub-resource change the state of the parent resource
              and I'd have to think more about whether that would have an impact on
              caches and RDF.

              As an analogy, what if SOAP were architected so that every method of
              every service needed its own URI. It would become difficult to reason
              about them as first-class objects and it would be inefficient to
              dereference the top-level resource to get at the method resources.
              --
              Come discuss XML and REST web services at:
              Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
              Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
            Your message has been successfully submitted and would be delivered to recipients shortly.