Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

No REST for the SOAPy? 3 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

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

    by Matts (1087) on 2002.04.26 4:41 (#7587) Journal
    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 development. And generally the sort of application you'd want to build with that level of interaction wouldn't need the firewall smashing that SOAP provides you with (actually that's probably quite naive of me - I guess a lot of corporations have internal as well as external firewalls - CORBA over HTTP anyone?)

    There's also a huge problem in concepts here. I think the REST people may have done huge damage to their cause by way too much hand waving, and by simply calling it "REST". I mean, "Representational State Transfer" - wtf is that supposed to mean to a web hacker???

    The irony is that REST has been with us since pretty much the dawn of the web. Google's original plain old HTML interface is a REST interface. It just happens to be for human consumption, not computer consumption. use.perl is a REST interface (again, for human consumption). You see REST is just the web as we know it from a browser. The REST technique is to simply allow that to work for a computer, by returning XML structures rather than HTML, that the computer can operate on.

    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. 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.

    And at the end of the day, most people just want to get their job done.

    • 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 alongsid

  • SOAP vs. REST (Score:3, Insightful)

    by ziggy (25) on 2002.04.26 15:28 (#7625) Journal
    Java found a place without displacing any other languages. Maybe REST can find a place without having to displace SOAP in the process.
    According to the REST folks, it's not an open playing field where the two could live in harmony. What's at stake is nothing less than the web as we know it. So while Java, Perl, C++ and C# can live in harmony in an open system we call the IT sector, SOAP and REST can't live in harmony in the closed system we call the Web.

    The key issue is this: there are some operations that are safe, and always return the same conceptual result: http://www.google.com/search?q=perl, http://www.news.com/, http://search.cpan.org/search?dist=perl. The way the web was designed, these resources are identified by their URLs, and should be retrievable with GET requests. They can then be referenced anywhere you can place a URL -- web pages, XPath expressions, XSLT stylesheets, RDF assertions, XLinks, etc.

    The issue behind putting resources such as this behind a POST request (using SOAP, XML-RPC or any other technique you care to use) is that such uses of HTTP POST have the nasty effect of hiding information and inhibiting it's use elsewhere on the web.

    OTOH, the SOAP advocates color this debate as simply a few academics crying for intellectual purity, aesthetic beauty and spilled milk because the other side "has won".

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.