Comments on: Coding Philosophy: as borrowed from Fish http://marshall-law.co.nz/2009/12/14/coding-philosophy-as-borrowed-from-fish/ Music | Code | Misanthropy Thu, 19 Aug 2010 21:53:41 +0000 hourly 1 http://wordpress.org/?v=3.0.1 By: Will Marshall http://marshall-law.co.nz/2009/12/14/coding-philosophy-as-borrowed-from-fish/comment-page-1/#comment-16 Will Marshall Thu, 17 Dec 2009 22:37:20 +0000 http://marshall-law.co.nz/?p=62#comment-16 SOAP ignores the defined methods of HTTP and tends to use them incorrectly. Perhaps semantically invalid isn't precisely the right term. SOAP ignores the defined methods of HTTP and tends to use them incorrectly. Perhaps semantically invalid isn’t precisely the right term.

]]> By: Joel http://marshall-law.co.nz/2009/12/14/coding-philosophy-as-borrowed-from-fish/comment-page-1/#comment-15 Joel Thu, 17 Dec 2009 22:29:15 +0000 http://marshall-law.co.nz/?p=62#comment-15 "SOAP is ... semantically invalid" Care to elucidate on that - it seems like a bit of stretch to claim that. “SOAP is … semantically invalid”

Care to elucidate on that – it seems like a bit of stretch to claim that.

]]> By: Will Marshall http://marshall-law.co.nz/2009/12/14/coding-philosophy-as-borrowed-from-fish/comment-page-1/#comment-14 Will Marshall Sun, 13 Dec 2009 21:29:58 +0000 http://marshall-law.co.nz/?p=62#comment-14 <em>SOAP, BTW, is extremely simple, much simpler than REST. REST requires significant additional complexity in both the browser and the server, in comparison to SOAP.</em> That's simply not true. REST is clean, simple and semantic. SOAP is bloated, relies on excessive configuration and is semantically invalid. Apart from anything else, SOAP essentially re-implements aspects of HTTP, which is bad form at best. There's an overview of the reasons people have stopped using SOAP for web-services at http://www.gen2phen.org/post/web-service-architecture-simple-rest-vs-complex-soap SOAP, BTW, is extremely simple, much simpler than REST. REST requires significant additional complexity in both the browser and the server, in comparison to SOAP.

That’s simply not true. REST is clean, simple and semantic. SOAP is bloated, relies on excessive configuration and is semantically invalid. Apart from anything else, SOAP essentially re-implements aspects of HTTP, which is bad form at best.

There’s an overview of the reasons people have stopped using SOAP for web-services at http://www.gen2phen.org/post/web-service-architecture-simple-rest-vs-complex-soap

]]> By: mundens http://marshall-law.co.nz/2009/12/14/coding-philosophy-as-borrowed-from-fish/comment-page-1/#comment-13 mundens Sun, 13 Dec 2009 21:00:27 +0000 http://marshall-law.co.nz/?p=62#comment-13 Hmm, I don't see how anything you say above could be seen as making fun of Java. SOAP, BTW, is extremely simple, much simpler than REST. REST requires significant additional complexity in both the browser and the server, in comparison to SOAP. They're also tools for completely different jobs. SOAP is designed for communication between servers, independantly of clients. None of the SOAP implementations I've worked on had any interaction with a browser or other client software, they were ways of sharing data between non-heterogenous backend servers such as IBM AS400 mini-computers, Sun SPARC stations, and Lucent network management systems, for instance. REST is designed for the client to be mediating the data exchange, which is useful in cross-site mash-ups mediated by browsers, but complete overkill for back-end systems that are continually connected to each other, and are executing thousands of transactions per second. Hmm, I don’t see how anything you say above could be seen as making fun of Java.

SOAP, BTW, is extremely simple, much simpler than REST. REST requires significant additional complexity in both the browser and the server, in comparison to SOAP.

They’re also tools for completely different jobs. SOAP is designed for communication between servers, independantly of clients. None of the SOAP implementations I’ve worked on had any interaction with a browser or other client software, they were ways of sharing data between non-heterogenous backend servers such as IBM AS400 mini-computers, Sun SPARC stations, and Lucent network management systems, for instance.

REST is designed for the client to be mediating the data exchange, which is useful in cross-site mash-ups mediated by browsers, but complete overkill for back-end systems that are continually connected to each other, and are executing thousands of transactions per second.

]]>