use Perl

• Bigger better SOAP apps (Score:4, Insightful)

  by Matts (1087)

  I think part of the problem is that nobody is actually building bigger SOAP apps that operate over the internet. The reason is that it's really damned hard to do that, because issues of statefulness, performance, scalability, balancing, and so on haven't been properly solved for SOAP yet. The funny thing is, if you need to build a large network application today, it's probably a hell of a lot easier and faster to use either DCOM or CORBA IIOP, and those systems have gone through a lot more debugging and dev
  • Re:Bigger better SOAP apps (Score:3, Informative)

    by ziggy (25) on 2002.04.26 15:13 (#7623) Journal

    The big problem REST faces is just that it's an uphill struggle. For SOAP/XMLRPC you already have an API, and we have modules for it in all languages. For REST you currently have to build your own API, even though it's conceptually much much more sensible on the wire.

    The biggest problem with REST is that it is purely conceptual. So the problem really isn't that there is a SOAP/XML-RPC API available, but REST is fundementally API-less.

    One step forward would be to develop a RESTful API to sit alongside SOAP.

    Nobody cares that much about what goes over the wire, as is evidenced by the popularity of many "inferior" technologies that just plain get the job done.

    There are a lot of straw men inhabiting htis discussion, and "over the wire representation" is possibly the weakest one of them all.

    What's really at issue here isn't the over-the-wire representation of a message, the efficiency of a transaction, or the elegant purity of a solution. The crux of the issue is integration of the web. Non-RESTful uses lead ghettoization of information: a simple request that hides behind a POST API can't be integrated into the rest of the web proper. This is what Dan Connolly describes [w3.org] as the proliferation of N > 1 webs.

    Reply to This

    Parent