Re: Why REST is a better way to do Web Services


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 3 of 3

Thread: Re: Why REST is a better way to do Web Services

  1. #1
    Michael D. Kersey Guest

    Re: Why REST is a better way to do Web Services

    Notes inline...
    David Bayley wrote:
    > Michael D. Kersey wrote:
    > > That's why REST is available today and easier to debug and develop
    > > than the RPC approach. [...]

    >
    > You've got that the wrong way around. Yes HTTP is available today, but
    > the reason that so many people are interested in Web Services are
    > because HTTP doesn't cut it.


    Nope, most currently plan to use Web Services by using SOAP-RPC,
    effectively "tunneling" through HTTP. That is a non-RESTful method which
    unduly clutters Web Services and raises all sorts of security and
    communications problems.

    > Web services however are
    > promoting the WS-Security standards, that maintain independence from
    > HTTP protocols. You're "may never" FUD, is clearly out of date.


    The WS-Security standards are mostly IBM's and Microsoft's standards
    formulated by the industry OASIS group.

    The W3C working groups have no similar security standards yet nor do
    they have a WS Security working group AFAIK.

    In contrast, HTTPS and SSL are available and used today in a RESTful
    fashion for RESTful Web Services.

    > What about Transaction standards? Perhaps these should be munged into
    > to the HTTP protocol as well. What about SMTP? Perhaps we should
    > should just discard that rather important messaging protocol, and munge
    > everything into HTTP headers?


    Transaction processing has been discussed, but is a problem that has no
    clear solution in a network on the scale of the internet. See the
    (well-respected and widely read) paper by Waldo et al at
    http://research.sun.com/techrep/1994/abstract-29.html
    describing why you don't want to make certain things (e.g.,
    transactions) transparent in a truly large-scale network. The paper
    addresses the problems that restrict transaction processing in that
    context: latency, concurrency, performance, partial failure and the lack
    of a central resource manager.

    > SOAP headers are a) independent of HTTP communication protocols, and b)
    > extensible through XML formats. HTTP headers are like ASCII INI files
    > in comparison.


    Yes, and you can use SOAP with HTTP in a RESTful manner. It's SOAP-RPC
    that Prescod et al object to.

    > FWIW, I started with one of the other Prescod articles you posted. I
    > found it far too abstract, and thought that this article presented the
    > case for REST extremely well (at least as well as possible given the
    > floored foundations). That was why I responded to it. If you can't
    > defend a well written case for REST, then don't expect me to go hunting
    > around all the other links you posted in search for an argument.


    Why didn't you ask the author? I'm sure Prescod would be willing to hear
    your objections and to address them.

    BTW If you don't understand an article, don't blame me. Know that it's
    not my responsibility to *make* you understand something, even were that
    possible. You've been given an opportunity to learn something. Quit
    being a whiner and engage your brain. See my earlier post today for *my*
    *view* (not Prescod's) of some answers to your questions.

    Finally if you don't have the patience to follow the W3C standards
    bodies and to see what the state of the standards that you reference
    truly is, then I must honestly ask why should anyone enter into a
    discussion with you?

    > > The true situation is that the W3C working groups on Web Services
    > > (there are several) have been discussing REST for quite some time but
    > > you and others haven't been listening. I suggest that you research
    > > other links concerning REST, especially the the W3C working groups on
    > > Web Services, to gain a better understanding of what you are missing.
    > > Note that Prescod was originally *NOT* a supporter of REST, but once
    > > he understood it, he became one of REST's most passionate proponents.
    > > Some links:

    >
    > I've already given my arguments against REST, and presumably
    > the rebel W3C community who agree with Prescod.


    They are W3C working groups members, previous members and invited
    experts. There is nothing "rebellious" about them. They are
    well-reasoned people who read and understand the standards and who will
    set new standards.

    > It doesn't supplant anything, it is just a bog standard hack of HTTP,
    > pushing it way beyond what it was designed for. And no, there is
    > nothing "arbitrary" about programmer-defined methods.


    RPC-SOAP methods *are* arbitrary, beginning with the naming of the
    methods, the arguments etc. In contrast, REST has the established
    methods of HTTP which, while small in number, appear to suffice in
    handling all problems presented to date. REST *does* require a change in
    approach however.

    > > There is no RPC protocol in use in any system on the scale of the
    > > internet. The only proven protocols on the internet of the scale
    > > demanded by Web Services are HTTP and email. And as the links above
    > > point out, and as discussed at W3C in the various Web Services working
    > > groups, there are *no* examples whatsoever of large-scale deployments
    > > of DCOM, CORBA or Java-RMI even remotely as large as those already
    > > done using REST. RPC architectures have proven successful only under
    > > very limited and controlled circumstances (e.g., within a single
    > > corporation or between two or three corporations where the developers
    > > could meet and coordinate software interfaces).

    >
    > This is absurd.
    > Of course HTML content over HTTP has been extremely
    > successful. Don't try to re-claim this success under the "REST" banner.


    Sorry, but the current WWW *is* REST. You might read parts of Roy
    Fielding's doctoral dissertation, wherein the term REST is coined.

    Q. Why should you read it?
    A. Because Fielding is one of the architects of the WWW. He helped
    design and build it and he understands and explains how it works and why
    it does work so well. Fielding's doctoral dissertation is
    "Representational State Transfer: An Architectural Style for Distributed
    Hypermedia Interaction" available at
    http://www.ics.uci.edu/~fielding/tal...9805/index.htm

    > This what I find most distasteful about your advocacy of REST. Web
    > Services are not out to achieve the scale of deployment that ZDNet's
    > "REST" HTML pages do.
    > The B2B market for RPC services is obviously more limited in scale.


    First I've heard of that!-))

    > What sort of straw man are you building trying to
    > compare compare Web Services with www.porn-r-us.com?


    If you are interested in porn, this is the wrong newsgroup.

    > > Security alone is a nightmare for RPC-SOAP Web Services: vendors are
    > > proposing special Web Services firewalls that look *inside* the SOAP
    > > envelope of each arriving Web Service request to determine whether it
    > > should be accepted. Such a "Web Services firewall" must
    > > 1) parse the SOAP envelope (an extremely compute-intensive operation)
    > > and
    > > 2) be programmed to recognize the particular RPC request as defined by
    > > the Web Service developer.
    > > What a nightmare! Certainly the hardware vendors are ready and willing
    > > to sell such products since to do so would require that *every*
    > > existing firewall be replaced by a "Web Services firewall"!

    >
    > I think you are looking at this the wrong way around. The indendence
    > from HTTP provides an *extensible* security model. If you just want to
    > stick with HTTP firewalls, then SOAP Web Services won't limit the
    > ability of existing firewalls in any way.


    AFAIK currently deployed firewalls cannot examine SOAP headers for
    proper method calls. So if an application is not properly written or if
    the programmer neglects the possibility of a buffer overflow attack,
    then the Web Service becomes an open gateway into the system.

    Of course the firewall vendors are working on ways to make new firewalls
    that can peer into the SOAP envelope. You can buy one to replace each of
    your (now supposedly defunct) firewalls!-))

    BTW another downside of this situation is that whomever currently
    configures firewalls will soon be responsible for SOAP firewall
    configuration too.

    But RESTful implementations of Web Services can be done today and on the
    same firewalls you've used for years. There's no need to wait for a WS
    security standard to be published or tools and special hardware to be
    created that may/not adhere to those standards. All the standards
    already exist and the firewall configuration is done in the same manner
    it currently is.
    Thisis because REST *is* the WWW.

    > > I leave it to the market to decide.

    > There is nothing to decide.


    Did I hear "Ve haff our vays. Zere is nosing to deside!"? No thanks,
    I'll leave it to the market.

    > REST is just a further hacking of HTTP that
    > has been hacked to death already.


    Au contraire, REST is beautiful and simple and works today.

    In stark contrast, RPC-SOAP Web Services are like the alien baby of the
    movie "Alien Resurrection": generated automagically by an unknown
    mechanism, complex, ugly to the eye, difficult to explain (especially
    their existence), they are dangerous even to their own mothers (their
    designers). SOAP-RPC Web Services are the true kludges of standards.

    Q. But just how ugly are RPC-SOAP Web Services?
    A. RPC-SOAP Web Services are so ugly that tools must be designed to hide
    their ugliness, arcanity and inefficiency from the programmer.

    Q. Who cares if they're ugly? They're still *my* babies! Waaahh!
    A. You will care! As Waldo's paper above points out, when you hide the
    presence of the network from the developer as is done with such tools,
    you introduce problems that will not go away until you reveal that
    ugliness. Sad thing is, RPC-SOAP is ugly enough to turn most
    programmer's brains to stone; seems it's happened to some people on
    these newsgroups already!-))

    > Web Services are a proposal for
    > consolidating the various RPC protocols that work on a completely
    > different level. Web Services _wrap_ HTTP, as well as TCP/IP, SMTP, and
    > any other communications protocol.


    You've got it backwards: in outbound messages, the lower protocols wrap
    the higher ones in envelopes and forward them to even lower protocols.
    The process is reversed for inbound messages. HTTP is an "application"
    level protocol - the highest level in the OSI 7-layer reference model.
    There is no higher level.

    See "Kicking out the Cuckoo" at
    http://www.xml.com/pub/a/2002/04/24/taglines.html
    which outlines briefly the genesis of RPC-SOAP Web Services, starting
    with Microsoft marketing and ending with a discussion of the time wasted
    by the W3C on standards for this ugly inefficient technology.

    Also see "Web Services: It's so Crazy It Just Might Not Work" at
    http://www.xml.com/pub/a/2001/10/03/webservices.html
    and many other fine articles on the controversial topic of Web Services
    at xml.com.

    Good Luck,
    Michael D. Kersey

  2. #2
    David Bayley Guest

    Re: Why REST is a better way to do Web Services

    Michael D. Kersey wrote:

    >> You've got that the wrong way around. Yes HTTP is available today,
    >> but the reason that so many people are interested in Web Services are
    >> because HTTP doesn't cut it.

    >
    > Nope, most currently plan to use Web Services by using SOAP-RPC,


    I thought that was what I just said?

    > effectively "tunneling" through HTTP. That is a non-RESTful method
    > which unduly clutters Web Services and raises all sorts of security
    > and communications problems.


    Actually, it is the RESTafarians that are trying to unduly clutter Web
    Services with HTTP, when the original charter was to be independent of
    HTTP. After reading some more, I see that SOAP 1.2 has made some
    compromises in order to support simple HTTP-GET access.

    The wonders of design-by-committee!!!

    > The WS-Security standards are mostly IBM's and Microsoft's standards
    > formulated by the industry OASIS group.


    Fair point. I think time is of the essence here, and standards groups
    move too slowly. Hopefully the de-facto standards will make their way
    into WC3.

    > In contrast, HTTPS and SSL are available and used today in a RESTful
    > fashion for RESTful Web Services.


    Yes, HTTP is available today, but this is not a valid argument against
    SOAP. Nothing happens overnight, even if you have to extend standards
    (WS-Security) to get things moving.

    > Transaction processing has been discussed, but is a problem that has
    > no clear solution in a network on the scale of the internet. See the
    > (well-respected and widely read) paper by Waldo et al at
    > http://research.sun.com/techrep/1994/abstract-29.html
    > describing why you don't want to make certain things (e.g.,
    > transactions) transparent in a truly large-scale network. The paper
    > addresses the problems that restrict transaction processing in that
    > context: latency, concurrency, performance, partial failure and the
    > lack of a central resource manager.


    1994?!? Regardless, references to the "scale of the internet" is
    loosely bandied about by the RESTafarians, and I've yet to see the
    relevance of that argument.

    If company ACME in the USA, wants to expose a Web Service to company X
    in the UK, company Y in Germany, and company Z in Siberia, then this is
    a scaling problem that has already been solved with TCP/IP and DNS.

    Web Services aren't attempting to solve the same scalability problems
    that Web Pages like those of Google or Yahoo do.

    > Why didn't you ask the author? I'm sure Prescod would be willing to
    > hear your objections and to address them.


    Sorry, have lived in the luxury of NNTP discussions forums, so I can't
    bear mailing lists, and even the RESTful web interfaces for viewing them
    are painful. ;^)

    I could see Web Services (the RPC kind) providing a perfectly good
    substitute to NNTP. Browser UI servers could dyanmically transform the
    XML messages into browser clients, and Fit UIs could handle the XML
    messages statefully in rich clients.

    > BTW If you don't understand an article, don't blame me. Know that it's
    > not my responsibility to *make* you understand something, even were
    > that possible. You've been given an opportunity to learn something.
    > Quit being a whiner and engage your brain. See my earlier post today
    > for *my* *view* (not Prescod's) of some answers to your questions.


    Watch it bozo! ;-) You were "whining" that I had only read one of the
    many links you posted. I merely pointed out, for what it was worth,
    that the first link I read was too abstract. The second one clarified
    the issue very well IMO, and since I disagreed with many of the
    premises, clarified why the first abstract one was useless.

    > Finally if you don't have the patience to follow the W3C standards
    > bodies and to see what the state of the standards that you reference
    > truly is, then I must honestly ask why should anyone enter into a
    > discussion with you?


    Err, to clear up this issue...

    1) It is the REST community that are disrupting the W3C Web Service
    standards. They may have a good case, but the debates are *live*.

    2) /You/ raised the issue of REST. I am merely defending the status
    quo of released SOAP/WSDL (aka Web Service) standards.

    3) I spent some time understanding the REST links you posted, and
    responded with what, I am confident, are some valid points.

    The ball was well and firmly in your court, and I'm glad you finally
    returned. But please, no more links, you've provided more than enough
    for a healthy discussion.

    [ This is dotnet.discussion so we can agree extremely viscously, with no
    worries about having to produce a standard at the end of it all. :-) ]

    > They are W3C working groups members, previous members and invited
    > experts. There is nothing "rebellious" about them. They are
    > well-reasoned people who read and understand the standards and who
    > will set new standards.


    Well, after reading the sales pitch, I went to W3C's ws-arch discussion
    forum to get a more balanced picture, and I still think that
    "rebellious" is the right term to use. I certainly don't use it
    negatively, since it is often positive. The implication is that it is
    fighting against accepted wisdom.

    > RPC-SOAP methods *are* arbitrary, beginning with the naming of the
    > methods, the arguments etc. In contrast, REST has the established
    > methods of HTTP which, while small in number, appear to suffice in
    > handling all problems presented to date. REST *does* require a change
    > in approach however.


    I agree that the SOAP/WSDL approach is different, but it it *less*
    arbitrary. It is the very arbitrary/generic nature of URI resources, as
    opposed to the defined/specific nature of WSDL services, that
    RESTafarians appear to be advocating AFAICT.

    > Sorry, but the current WWW *is* REST. You might read parts of Roy
    > Fielding's doctoral dissertation, wherein the term REST is coined.


    Yes, we are in viscous agreement here.

    >> This what I find most distasteful about your advocacy of REST. Web
    >> Services are not out to achieve the scale of deployment that ZDNet's
    >> "REST" HTML pages do.
    >> The B2B market for RPC services is obviously more limited in scale.

    >
    > First I've heard of that!-))


    This is something I've always assumed, but I see the folks on ws-arch
    are coming to the same conclusion (June/July archives). B2C
    opportunities, are inherently far larger in scale than than B2B
    opportunities. B2B links are limited to business partnerships. Also,
    computers/businesses need defined contracts in order to communicate,
    whereas consumers are orders of magnitude more flexible/intelligent.

    The "Web" and "Scalability" are orthogonal concepts.

    > AFAIK currently deployed firewalls cannot examine SOAP headers for
    > proper method calls. So if an application is not properly written or
    > if the programmer neglects the possibility of a buffer overflow
    > attack, then the Web Service becomes an open gateway into the system.
    >
    > Of course the firewall vendors are working on ways to make new
    > firewalls that can peer into the SOAP envelope. You can buy one to
    > replace each of your (now supposedly defunct) firewalls!-))


    Yes a valid, albeit transitional point. This boils down to the
    "protocol independence" argument, and firewall vendors will need to
    adapt like everyone else. The advantage though, is that SOAP headers
    are XML based, and so more expressive than HTTP and port numbers.

    > But RESTful implementations of Web Services can be done today and on
    > the same firewalls you've used for years. There's no need to wait for
    > a WS security standard to be published or tools and special hardware
    > to be created that may/not adhere to those standards. All the
    > standards already exist and the firewall configuration is done in the
    > same manner it currently is.


    The "no need to wait" argument has never prevented the progression of
    more sophisticated technology, but it can delay it.

    > Did I hear "Ve haff our vays. Zere is nosing to deside!"? No thanks,
    > I'll leave it to the market.


    Oops, sorry... No, that is not what I meant. Everything businesses need
    for the RESTful architecture is here today, and in fact yester-year, in
    the shape of HTTP/XML.

    There is nothing to decide, because despite the availablitity of RESTful
    standards, it hasn't been adopted. Instead, business are looking to the
    higher level abstraction of Web Services (SOAP/WSDL).

    --
    David




  3. #3
    Michael D. Kersey Guest

    Re: Why REST is a better way to do Web Services

    Notes inline...
    David Bayley wrote:
    > Actually, it is the RESTafarians that are trying to unduly clutter Web
    > Services with HTTP, when the original charter was to be independent of
    > HTTP. After reading some more, I see that SOAP 1.2 has made some
    > compromises in order to support simple HTTP-GET access.
    > The wonders of design-by-committee!!!


    Yes, indeed, the GET was something that REST supporters requested and
    got, so that Web Services would remain compatible with the existing WWW
    design.

    > > See the
    > > (well-respected and widely read) paper by Waldo et al at
    > > http://research.sun.com/techrep/1994/abstract-29.html
    > > describing why you don't want to make certain things (e.g.,
    > > transactions) transparent in a truly large-scale network. The paper
    > > addresses the problems that restrict transaction processing in that
    > > context: latency, concurrency, performance, partial failure and the
    > > lack of a central resource manager.

    >
    > 1994?!?


    It was a good year?-)) But really now, good research done anytime is
    still good. The theory of relativity was conceived of in the early
    1900's and is still good. The Waldo paper is interesting, although
    somewhat of a downer for me.

    > Regardless, references to the "scale of the internet" is
    > loosely bandied about by the RESTafarians, and I've yet to see the
    > relevance of that argument.


    I think the relevance was largely hidden from us, since the very people
    who architected the WWW during it's period of greatest growth were very
    busy then, but were the same people who later explicated their
    architecture as REST.

    > If company ACME in the USA, wants to expose a Web Service to company X
    > in the UK, company Y in Germany, and company Z in Siberia, then this is
    > a scaling problem that has already been solved with TCP/IP and DNS.
    >
    > Web Services aren't attempting to solve the same scalability problems
    > that Web Pages like those of Google or Yahoo do.


    This is undoubtedly true, especially early in the adoption process. But
    later when your firm merges with another and your boss tells you to
    extend those Web Services formerly used by 12 clients to another 10,000,
    something may hit the fan!

    > > Why didn't you ask the author? I'm sure Prescod would be willing to
    > > hear your objections and to address them.

    >
    > Sorry, have lived in the luxury of NNTP discussions forums, so I can't
    > bear mailing lists, and even the RESTful web interfaces for viewing them
    > are painful. ;^)


    Ha! And I couldn't agree more. But I have met surprising resistance
    (perhaps "inertia" would be a better term) when introducing NNTP into
    corporate environments. I am constantly amazed that individuals who have
    no trouble with email can be paralyzed by a newsgroup. Newsgroups are an
    incredible collaborative tool and IMO greatly underutilized.

    > I could see Web Services (the RPC kind) providing a perfectly good
    > substitute to NNTP. Browser UI servers could dyanmically transform the
    > XML messages into browser clients, and Fit UIs could handle the XML
    > messages statefully in rich clients.


    These are several very good ideas, since those people who are so wary of
    NNTP are fearless before a WWW interface.

    > > BTW If you don't understand an article, don't blame me. Know that it's
    > > not my responsibility to *make* you understand something, even were
    > > that possible. You've been given an opportunity to learn something.
    > > Quit being a whiner and engage your brain. See my earlier post today
    > > for *my* *view* (not Prescod's) of some answers to your questions.

    >
    > Watch it bozo! ;-) You were "whining" that I had only read one of the
    > many links you posted. I merely pointed out, for what it was worth,
    > that the first link I read was too abstract. The second one clarified
    > the issue very well IMO, and since I disagreed with many of the
    > premises, clarified why the first abstract one was useless.
    >
    > > Finally if you don't have the patience to follow the W3C standards
    > > bodies and to see what the state of the standards that you reference
    > > truly is, then I must honestly ask why should anyone enter into a
    > > discussion with you?

    >
    > Err, to clear up this issue...
    >
    > 1) It is the REST community that are disrupting the W3C Web Service
    > standards. They may have a good case, but the debates are *live*.


    They're part of the standards process and they've brought a great deal
    to the standards.

    > 2) /You/ raised the issue of REST. I am merely defending the status
    > quo of released SOAP/WSDL (aka Web Service) standards.
    >
    > 3) I spent some time understanding the REST links you posted, and
    > responded with what, I am confident, are some valid points.
    >
    > The ball was well and firmly in your court, and I'm glad you finally
    > returned. But please, no more links, you've provided more than enough
    > for a healthy discussion.
    >
    > [ This is dotnet.discussion so we can agree extremely viscously, with no
    > worries about having to produce a standard at the end of it all. :-) ]


    Well, you're spot-on on these points, and I feel like a troll. Think
    I'll go crawl under a bridge somewhere and sulk after writing this. My
    apologies: sometimes even trolls get excited about ideas.

    > > They are W3C working groups members, previous members and invited
    > > experts. There is nothing "rebellious" about them. They are
    > > well-reasoned people who read and understand the standards and who
    > > will set new standards.

    >
    > Well, after reading the sales pitch, I went to W3C's ws-arch discussion
    > forum to get a more balanced picture, and I still think that
    > "rebellious" is the right term to use. I certainly don't use it
    > negatively, since it is often positive. The implication is that it is
    > fighting against accepted wisdom.
    >
    > > RPC-SOAP methods *are* arbitrary, beginning with the naming of the
    > > methods, the arguments etc. In contrast, REST has the established
    > > methods of HTTP which, while small in number, appear to suffice in
    > > handling all problems presented to date. REST *does* require a change
    > > in approach however.

    >
    > I agree that the SOAP/WSDL approach is different, but it it *less*
    > arbitrary. It is the very arbitrary/generic nature of URI resources, as
    > opposed to the defined/specific nature of WSDL services, that
    > RESTafarians appear to be advocating AFAICT.


    But while a URI can be arbitrary, it is *exposed* and available on the
    WWW. You can cut and paste it, write it on an envelope and mail it. You
    can examine it's contents with a browser. Everything required in
    processing is exposed.

    And REST's limited set of methods (GET, POST, PUT, DELETE) simplifies
    the publication and coordination of interfaces. Everyone knows how to
    GET a URI, and POSTing XML to another URI is also straightforward (PUT
    and DELETE are usually hidden, but IMO are easily explained and don't
    have the nuances of GET and POST in the REST context).

    IMO the difficult part of REST is the idea that the various URIs that
    exist or may be created in an application or Web Service are actually
    the states of a giant web-based virtual state machine, and that, as
    operations are performed the application or Web Service moves from one
    state(URI) to another.

    The bad news is that AFAICT the REST style isn't object-oriented in the
    usual sense. In contrast, SOAP-RPC has evolved from a design perspective
    that is totally traditional OOP. So I'm not surprised that REST met
    resistance not only for it's surprising and possibly unwelcome late
    emergence (something like the swamp monster during a trout-fishing
    tournament) but also because REST's implementation doesn't square with
    the OOP paradigm that developers have been trying to use the last
    decade.

    The good news is that REST is extremely scaleable and robust because
    - state is captured in the URIs,
    - because URIs can be cached for performance, and
    - because it requires no changes from the existing WWW and supporting
    network (the Internet and it's hardware) to implement.

    > > Sorry, but the current WWW *is* REST. You might read parts of Roy
    > > Fielding's doctoral dissertation, wherein the term REST is coined.

    >
    > Yes, we are in viscous agreement here.
    >
    > >> This what I find most distasteful about your advocacy of REST. Web
    > >> Services are not out to achieve the scale of deployment that ZDNet's
    > >> "REST" HTML pages do.
    > >> The B2B market for RPC services is obviously more limited in scale.

    > >
    > > First I've heard of that!-))

    >
    > This is something I've always assumed, but I see the folks on ws-arch
    > are coming to the same conclusion (June/July archives). B2C
    > opportunities, are inherently far larger in scale than than B2B
    > opportunities. B2B links are limited to business partnerships. Also,
    > computers/businesses need defined contracts in order to communicate,
    > whereas consumers are orders of magnitude more flexible/intelligent.


    This is no doubt true. but...

    > The "Web" and "Scalability" are orthogonal concepts.

    We disagree here: IMO the WWW is eminently scalable due to the RESTful
    architecture. And violating the architectural constraints of REST will
    reduce the scalability of an application or Web Service.

    > > AFAIK currently deployed firewalls cannot examine SOAP headers for
    > > proper method calls. So if an application is not properly written or
    > > if the programmer neglects the possibility of a buffer overflow
    > > attack, then the Web Service becomes an open gateway into the system.
    > >
    > > Of course the firewall vendors are working on ways to make new
    > > firewalls that can peer into the SOAP envelope. You can buy one to
    > > replace each of your (now supposedly defunct) firewalls!-))

    >
    > Yes a valid, albeit transitional point. This boils down to the
    > "protocol independence" argument, and firewall vendors will need to
    > adapt like everyone else. The advantage though, is that SOAP headers
    > are XML based, and so more expressive than HTTP and port numbers.


    Certainly SOAP headers are more expressive than HTTP headers. But
    HTTP+XML is RESTful and should more than suffice.

    I am surprised that the W3C working groups have not recommended that Web
    Services exist on a port or ports separate from those currently reserved
    for WWW HTTP(S)(80 and 443). On concern I have is that problematic Web
    Services activity may interfere with a previously perfectly functioning
    WWW. A more paranoid perspective is that this will happen *by design*.

    > > But RESTful implementations of Web Services can be done today and on
    > > the same firewalls you've used for years. There's no need to wait for
    > > a WS security standard to be published or tools and special hardware
    > > to be created that may/not adhere to those standards. All the
    > > standards already exist and the firewall configuration is done in the
    > > same manner it currently is.

    >
    > The "no need to wait" argument has never prevented the progression of
    > more sophisticated technology, but it can delay it.
    >
    > > Did I hear "Ve haff our vays. Zere is nosing to deside!"? No thanks,
    > > I'll leave it to the market.

    >
    > Oops, sorry... No, that is not what I meant. Everything businesses need
    > for the RESTful architecture is here today, and in fact yester-year, in
    > the shape of HTTP/XML.
    >
    > There is nothing to decide, because despite the availablitity of RESTful
    > standards, it hasn't been adopted. Instead, business are looking to the
    > higher level abstraction of Web Services (SOAP/WSDL).
    > --
    > David


    The inclusion of GET in the SOAP specification allows RESTful Web
    Services to be part of the standards. But certainly it appears today
    that most businesses who are rushing at all, are rushing to RPC-SOAP.
    Whether they drown in the swamp or are saved by the swamp monster is a
    matter for a later day.

    Good Luck,
    Michael D. Kersey

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center