• « NOTE-TO-SELF:
    • |
    • Main
    • |
    • On Good/Bad OSS, OSS 'Business Models', and Its Relationship to the REST/SOAP Religous Debate [Part 2 of a Mini-Series] »
            • February 23, 2006

              REST? SOAP? I Could Care Less... It's All About Sending And Receiving Messages : [Part 1 of a Mini-Series]

            • So here's the dealio, yo: I 100% agree with both Mike and Don and anyone else who agrees with their point.

              The most important piece to all of this chat-chat-chattering going on in the blogosphere seems to be overlooked. No matter which way you slice it, it's all about the messaging.

              REST+POX? SOAP? These "questions" shouldn't be seen as a dividing line "one over the other" and instead "Is REST+POX enough or do I need SOAP to accomplish the task at hand?"

              If I want to toy around with some pic's on Flickr, the chances of me needing the complexities of SOAP are pretty slim. If I want to ensure that a financial transaction has met the "Atomic" requirement of completing the entire transaction successfully or backing out of the entire transaction, then SOAP *IS* required!

              Actually, thats not true.

              I guess you could go invent your own XML messaging framework for complex transactions, but my guess is that in the end it would look a lot like SOAP, so why not just use SOAP and be done with it?

              "Because that would mean *THEY* won and *WE* lost?"

              Huh? Man, come on, go buy a damn clue.

              This *ISN'T* a religous battle. This *ISN'T* about "one or the other, but not both!"

              *IT IS* about which one do you need to get the job done. End of Story. (but not of post... yeah, yeah, cry me a river... you'll get over it. ;)

              For those of you who are still a bit confused, here's some general guidance:

              Sometimes the message being sent it lightweight and *DOESN'T* require a lot of overhead. In such cases a REST+POX solution makes sense. The reason REST+POX gets so much hype is because its:

              * Simple, so any member of the "View Source" generation can figure out how it works and how to use it.
              * Efficient - Low overhead because it uses an extremely cheap carrier pigeon in HTTP

              Sometime the message being sent is heavy and *DOES* require a lot of overhead. Sometimes a complex set of structured information is required, and sometimes you can't just "Let go, and Let God". You need a response, and your not going to hang up the phone until you get one. Carrier-Pigeons might be able to deliver the message, but counting on them to wait for a return response, to then bring that response back to you isn't always the best strategy. In such cases a SOAP-based solution makes sense. The reason SOAP gets so much flack is because its:

              * (see points regarding overhead and complexity)

              Whether we "I don't see type's, I see (please fill in you prefered variation of the Matrix cliche' quote here)" folk's want to admit it or not, there *IS* a need for this type (oh, can I say that word and not be beaten down by the Society of the Politically Correct Hackers of the Type-Less Mind"? If not... I'm ready. Bring It.) of "Heavy Messaging" *IS NECESSARY*.

              Whether the HTTP aficionados want to admit it or not, HTTP *DOESN'T* solve 100% of the problems. In a lot of cases, like GETting information from a web server, or POSTing information to a web server (a message to a forum, etc...) HTTP gets the job done, and we're happy. A lot of traffic on the web can be served quite happily with HTTP as it doesn't need anything beyond this to accomplish the task at hand.

              Great! Fantastic! Wonderful! Well, until you need something a bit more industrial strength that goes beyond what the stateless verbs GET, POST, DELETE, PUT (Can I say that word and not be beaten the SPCHTLM? If not, please see previous prompting :), etc... that HTTP brings to the table. When this happens to be the case, then no matter how how hard you try, HTTP *ISN'T* going to get the job done.

              So here's the extended dealio, yo:

              * The majority of the web population is served with a REST+POX solution.
              * More People = More Voices = Loud (sometimes annoying) Chatter
              * = "Hmmm... How can we profit off of this?"
              * = "I know! Lets start a religous movement so we can RAKE In All The 'Sucker Dough' While We Plead Our 'Evil! Evil! Evil!' case."
              * = The "Send me your weak, and your old, and I will give them REST!" Gospel Hour
              * = RAKE in even more "Sucker Dough" while we plead Our "Evil! Evil! Evil!" case!
              * = The "Send me your weak, and your old, and I will give them REST!" Cable Channel

              [UPDATE: those last two were in the wrong order because and unfortunate copy/paste "incident". Don't worry, no line-items were harmed during the recording of this post. Just re-ordered a bit, and added to.]

              Does the term "Please Donate" sound all to common and familiar to any of you? [UPDATE: See Part 2 of this mini-series for a further understanding of what I mean.]

              Think about it.

              Your being taken for a ride folks. If REST+POX is all you need, then don't worry about using SOAP. If its not. Then do. End of Story. (and of post. But not Mini-Series. Oh yes, theres more to come. You can believe 'dat!)


            • Posted by m.david : February 23, 2006 01:34 PM GMT

            Trackback Pings

            TrackBack URL for this entry:
            http://www.xsltblog.com/xslt-blog-mt/mt-tb.cgi/1386

            Comments

            Post a comment




            Remember Me?

            (you may use HTML tags for style)

          • © 2005 :: <XSLT:Blog/> (xsltblog.com) is a product of M. David Peterson and FunctionalX Consulting. See Licensing Info Below.
          • Except where otherwise noted, this sites content and source code is licensed under the Attribution License from Creative Commons.