Sign In/My Account | View Cart  

advertisement

AddThis Social Bookmark Button

Weblog:   Web Services, Weblogs and the Future.
Subject:   Use SOAP
Date:   2003-05-25 02:00:23
From:   anonymous2
SOAP is a great service, supported by all the big players.
Full Threads Oldest First

Showing messages 1 through 5 of 5.

  • Use SOAP
    2003-05-26 11:59:18  anonymous2 [View]

    SOAP is a useless waste of time and a wonderful example of NeedlessComplexity. Use HTTP. What else needs to be done besides GETting data, POSTing new data, PUTing changed data and DELETEing dead data? Focus on clean resource-space identifiers [URIs] and meaningful XML blocks. Then, DO NOT wrap them in an XML-RPC or SOAP noise. Just use the data. Focus on getting the existing tools [Mozilla, IE, Opera] to deal with authentication and POST/PUT correctly, rather than creating a whole set of tools. We have a good protocol [http] and a simple way to describe data-languages [xml] -- let's use them.
    • Timothy Appnel photo SOAP w/ RSS could be simpler then you think.
      2003-05-29 07:42:04  Timothy Appnel | O'Reilly Blogger [View]

      I understand where you are coming from here and would suggest an approach that would allow for both.

      Creating a SOAP/RSS hybrid would simpler then most people think when document literal encoding is applied. (Most are familar with the RPC encoding which does have more overhead and issues particularly in this case.) Sam demonstrates that at the end of his essay. http://www.intertwingly.net/stories/2003/01/26/evolve.html#SOAP

      Here is some additional reading on the matter:
      http://www.intertwingly.net/blog/1112.html
      http://www.intertwingly.net/blog/1010.html
      http://www.snellspace.com/blog/archives/000127.html

      SOAP does have its place. Wouldn't it be helpful to post to your weblog via an email message? (This assumes the client is handling the SOAP encoding of course.)
    • Use SOAP
      2003-05-28 18:38:31  anonymous2 [View]

      Agreed on SOAP. Simple it Ain't.

      On HTTP, you have to handle types (is is a date? Is it an integer? Is it a string?) on the server, and you'd have to know what it is, because 06116 is a zip code, a string, not an integer, so for every item of data, you'd have to send the type too, as in Val=06116&Type=String. But what if you're sending 3 values in a row? Which type applies to which value? or do you number them? as:

      val1=06116&type1=string&val2=04&type2=integer&val3=Connecticut&type3=string

      for:
      ZipCode 06116
      StateCode 04
      StateName Connecticut

      Then you end up with a parsing nightmare, with arrays, and how large are the arrays... So on and so forth.

      Trust me, for structs, it would not be pretty.

      • Data in the XML not the URL
        2003-06-19 18:29:32  anonymous2 [View]

        If the server doesn't know how to deal with the untyped data in a URL, having clients send that extra data won't help - how will it know that the client is /wrong/?

        If you need strong typing, put it in the body of the request message, not the resource identifier.

        The resource identifier (URI) isn't (shouldn't be) different if the zipcode is identified as an integer .vs. text.
      • Data in the XML not the URL
        2003-06-19 18:26:32  anonymous2 [View]

        If the server doesn't know how to deal with the untyped data in a URL, having clients send that extra data won't help - how will it know that the client is /wrong/?

        If you need strong typing, put it in the body of the request message, not the resource identifier.

        The resource identifier (URI) isn't (shouldn't be) different if the zipcode is identified as an integer .vs. text.

Showing messages 1 through 5 of 5.