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.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • 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