<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.1.3" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Reacties op: Kiezen tussen SOAP en REST</title>
	<link>http://blog.finalist.com/2007/11/26/kiezen-tussen-soap-en-rest/</link>
	<description>Nederlandse blog over software ontwikkeling</description>
	<pubDate>Thu, 16 Oct 2008 00:26:36 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.1.3</generator>

	<item>
		<title>By: Remco van 't Veer</title>
		<link>http://blog.finalist.com/2007/11/26/kiezen-tussen-soap-en-rest/#comment-13972</link>
		<author>Remco van 't Veer</author>
		<pubDate>Mon, 26 Nov 2007 14:40:28 +0000</pubDate>
		<guid>http://blog.finalist.com/2007/11/26/kiezen-tussen-soap-en-rest/#comment-13972</guid>
					<description>REST authenticatie hoeft geen maatwerk te zijn als je HTTP authenticatie zoals basic of digest gebruikt.

Wat performance betreft kan REST veel beter gebruik maken van HTTP caching mechanismes.  Dit betekent dat je als je gebruik maakt van expires-, etags- en if-modified-since headers, je simpelweg caching proxies tussen je applicaties kan plaatsen.</description>
		<content:encoded><![CDATA[<p>REST authenticatie hoeft geen maatwerk te zijn als je HTTP authenticatie zoals basic of digest gebruikt.</p>
<p>Wat performance betreft kan REST veel beter gebruik maken van HTTP caching mechanismes.  Dit betekent dat je als je gebruik maakt van expires-, etags- en if-modified-since headers, je simpelweg caching proxies tussen je applicaties kan plaatsen.</p>
]]></content:encoded>
				</item>
	<item>
		<title>By: Erik van Oosten</title>
		<link>http://blog.finalist.com/2007/11/26/kiezen-tussen-soap-en-rest/#comment-14059</link>
		<author>Erik van Oosten</author>
		<pubDate>Tue, 27 Nov 2007 20:04:15 +0000</pubDate>
		<guid>http://blog.finalist.com/2007/11/26/kiezen-tussen-soap-en-rest/#comment-14059</guid>
					<description>Een klein beetje afhankelijk van hoe je het opzet, maar in principe zijn POSTs eenvoudig te testen met een eenvoudige html pagina. Hierbij is de REST stijl waarschijnlijk gemakkelijker te testen dan de SOAP stijl. Daar komt bij dat de tester de html gemakkelijker kan controleren dan een SOAP test tool.</description>
		<content:encoded><![CDATA[<p>Een klein beetje afhankelijk van hoe je het opzet, maar in principe zijn POSTs eenvoudig te testen met een eenvoudige html pagina. Hierbij is de REST stijl waarschijnlijk gemakkelijker te testen dan de SOAP stijl. Daar komt bij dat de tester de html gemakkelijker kan controleren dan een SOAP test tool.</p>
]]></content:encoded>
				</item>
	<item>
		<title>By: Rudie Ekkelenkamp</title>
		<link>http://blog.finalist.com/2007/11/26/kiezen-tussen-soap-en-rest/#comment-14181</link>
		<author>Rudie Ekkelenkamp</author>
		<pubDate>Thu, 29 Nov 2007 09:10:42 +0000</pubDate>
		<guid>http://blog.finalist.com/2007/11/26/kiezen-tussen-soap-en-rest/#comment-14181</guid>
					<description>Met het gevaar te generaliseren, denk ik dat HTTP caching vooral zinvol is voor resources zoals documenten, images, statische pagina's etc.. 
De meeste webservice operaties voldoen daar over het algemeen niet aan en is caching vooral nuttig op database query niveau, zoals bijvoorbeeld de second level cache van Hibernate.

En wat het testen betreft, een nadeel van het opzetten van een HTML pagina voor een tester is dat je die pagina dan ook moet onderhouden.
Er zijn ondertussen voldoende tools die vanuit een WSDL automatisch een HTML formulier genereren waarmee een tester prima uit de voeten kan. 
Zie bijvoorbeeld: http://www.soapclient.com/soaptest.html of het Web Tools Project van Eclipse.</description>
		<content:encoded><![CDATA[<p>Met het gevaar te generaliseren, denk ik dat HTTP caching vooral zinvol is voor resources zoals documenten, images, statische pagina&#8217;s etc..<br />
De meeste webservice operaties voldoen daar over het algemeen niet aan en is caching vooral nuttig op database query niveau, zoals bijvoorbeeld de second level cache van Hibernate.</p>
<p>En wat het testen betreft, een nadeel van het opzetten van een HTML pagina voor een tester is dat je die pagina dan ook moet onderhouden.<br />
Er zijn ondertussen voldoende tools die vanuit een WSDL automatisch een HTML formulier genereren waarmee een tester prima uit de voeten kan.<br />
Zie bijvoorbeeld: <a href="http://www.soapclient.com/soaptest.html" rel="nofollow">http://www.soapclient.com/soaptest.html</a> of het Web Tools Project van Eclipse.</p>
]]></content:encoded>
				</item>
	<item>
		<title>By: M@c</title>
		<link>http://blog.finalist.com/2007/11/26/kiezen-tussen-soap-en-rest/#comment-15544</link>
		<author>M@c</author>
		<pubDate>Fri, 04 Jan 2008 07:46:40 +0000</pubDate>
		<guid>http://blog.finalist.com/2007/11/26/kiezen-tussen-soap-en-rest/#comment-15544</guid>
					<description>Er is WADL voor REST. Dat heeft nog niet de status van WSDL voor SOAP maar het is beter dan een papieren contract. Bovendien kun je dan wel degelijk client stubs genereren.Zie https://wadl.dev.java.net/

Voor java is er nog de REST ontwikkelomgeving Restlet: http://www.restlet.org/</description>
		<content:encoded><![CDATA[<p>Er is WADL voor REST. Dat heeft nog niet de status van WSDL voor SOAP maar het is beter dan een papieren contract. Bovendien kun je dan wel degelijk client stubs genereren.Zie <a href="https://wadl.dev.java.net/" rel="nofollow">https://wadl.dev.java.net/</a></p>
<p>Voor java is er nog de REST ontwikkelomgeving Restlet: <a href="http://www.restlet.org/" rel="nofollow">http://www.restlet.org/</a></p>
]]></content:encoded>
				</item>
</channel>
</rss>
