<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments on: To WADL or not to WADL</title>
	<atom:link href="http://bill.burkecentral.com/2009/05/21/to-wadl-or-not-to-wadl/feed/" rel="self" type="application/rss+xml" />
	<link>http://bill.burkecentral.com/2009/05/21/to-wadl-or-not-to-wadl/</link>
	<description>Software plumbing using middleware wrenches</description>
	<lastBuildDate>Mon, 23 Jan 2012 15:53:14 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
	<item>
		<title>By: Constantine</title>
		<link>http://bill.burkecentral.com/2009/05/21/to-wadl-or-not-to-wadl/#comment-3309</link>
		<dc:creator><![CDATA[Constantine]]></dc:creator>
		<pubDate>Thu, 28 Jan 2010 09:58:26 +0000</pubDate>
		<guid isPermaLink="false">http://bill.burkecentral.com/?p=227#comment-3309</guid>
		<description><![CDATA[I think that WADL helps to implement clients in a client-server architecture. I imagine writing Java client for the complex HATEOAS web service with lots of possible states... With WADL this step can be completely automated, though you won&#039;t have some state constraints. Same is true about test cases and documentation - nowadays there exist quite a few generators utilizing WADL, you can find some examples &lt;a href=&quot;http://wintermuteblog.blogspot.com/2010/01/wadl-toolbox.html&quot; rel=&quot;nofollow&quot;&gt;here&lt;/a&gt;.

Also, WADL gives you a standard way to document your interfaces. For example, you can specify not only the representations, fault codes and so on, but also (links to) some business constraints affecting the behavior of your server (you can attach documentation to any element in WADL, so it will be easier for your users to find it).

Speaking about your schema idea... It seems to me that transferring all the information about the service (allowed methods, fault codes, etc) is a bad idea (at least, it&#039;s an overhead). Instead, it is better to provide only an URL pointing at some definition, for example to WADL :) Think of the schema itself - normally we don&#039;t put its contents into every XML file, we use xsd:schemaLocation instead.]]></description>
		<content:encoded><![CDATA[<p>I think that WADL helps to implement clients in a client-server architecture. I imagine writing Java client for the complex HATEOAS web service with lots of possible states&#8230; With WADL this step can be completely automated, though you won&#8217;t have some state constraints. Same is true about test cases and documentation &#8211; nowadays there exist quite a few generators utilizing WADL, you can find some examples <a href="http://wintermuteblog.blogspot.com/2010/01/wadl-toolbox.html" rel="nofollow">here</a>.</p>
<p>Also, WADL gives you a standard way to document your interfaces. For example, you can specify not only the representations, fault codes and so on, but also (links to) some business constraints affecting the behavior of your server (you can attach documentation to any element in WADL, so it will be easier for your users to find it).</p>
<p>Speaking about your schema idea&#8230; It seems to me that transferring all the information about the service (allowed methods, fault codes, etc) is a bad idea (at least, it&#8217;s an overhead). Instead, it is better to provide only an URL pointing at some definition, for example to WADL <img src='http://s0.wp.com/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' />  Think of the schema itself &#8211; normally we don&#8217;t put its contents into every XML file, we use xsd:schemaLocation instead.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Rickoshay</title>
		<link>http://bill.burkecentral.com/2009/05/21/to-wadl-or-not-to-wadl/#comment-2889</link>
		<dc:creator><![CDATA[Rickoshay]]></dc:creator>
		<pubDate>Tue, 04 Aug 2009 00:39:26 +0000</pubDate>
		<guid isPermaLink="false">http://bill.burkecentral.com/?p=227#comment-2889</guid>
		<description><![CDATA[I&#039;m sure various schema will emerge but it&#039;s not something a REST architecture needs. The idea of opaque URIs seems to be a core value proposition of the architecture. REST separates the concerns of parsing URIs by making assuming they have no distinguishing characteristics. 

GET and PUT are fine but what if we need to hop, skip and jump and if so how high or far, and what object are we presumably directing? The rich API accessible via RPC looks rather compelling to the average programmer at that point... until they look at JAX-RS. 

So, JAX-RS makes it a breeze to implement the richness of behavior we are looking for by adding semantics to those otherwise meaningless URIs. Ad hoc interpretation works, but layering on some schema definition is fine, too. As long as it&#039;s not confused with REST, no problem.]]></description>
		<content:encoded><![CDATA[<p>I&#8217;m sure various schema will emerge but it&#8217;s not something a REST architecture needs. The idea of opaque URIs seems to be a core value proposition of the architecture. REST separates the concerns of parsing URIs by making assuming they have no distinguishing characteristics. </p>
<p>GET and PUT are fine but what if we need to hop, skip and jump and if so how high or far, and what object are we presumably directing? The rich API accessible via RPC looks rather compelling to the average programmer at that point&#8230; until they look at JAX-RS. </p>
<p>So, JAX-RS makes it a breeze to implement the richness of behavior we are looking for by adding semantics to those otherwise meaningless URIs. Ad hoc interpretation works, but layering on some schema definition is fine, too. As long as it&#8217;s not confused with REST, no problem.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: PB</title>
		<link>http://bill.burkecentral.com/2009/05/21/to-wadl-or-not-to-wadl/#comment-2760</link>
		<dc:creator><![CDATA[PB]]></dc:creator>
		<pubDate>Wed, 27 May 2009 05:35:05 +0000</pubDate>
		<guid isPermaLink="false">http://bill.burkecentral.com/?p=227#comment-2760</guid>
		<description><![CDATA[How about just a page with some examples of it in various permutations. I liked your idea of something &quot;schema like&quot; to describe the structured data when its not obvious. Really, its a human developer that will be gluing this together, code generators will only do so much (and poorly) so just make it friendly, humane.]]></description>
		<content:encoded><![CDATA[<p>How about just a page with some examples of it in various permutations. I liked your idea of something &quot;schema like&quot; to describe the structured data when its not obvious. Really, its a human developer that will be gluing this together, code generators will only do so much (and poorly) so just make it friendly, humane.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Michael Neale</title>
		<link>http://bill.burkecentral.com/2009/05/21/to-wadl-or-not-to-wadl/#comment-2739</link>
		<dc:creator><![CDATA[Michael Neale]]></dc:creator>
		<pubDate>Thu, 21 May 2009 23:49:30 +0000</pubDate>
		<guid isPermaLink="false">http://bill.burkecentral.com/?p=227#comment-2739</guid>
		<description><![CDATA[How about just a page with some examples of it in various permutations. I liked your idea of something &quot;schema like&quot; to describe the structured data when its not obvious. Really, its a human developer that will be gluing this together, code generators will only do so much (and poorly) so just make it friendly, humane.]]></description>
		<content:encoded><![CDATA[<p>How about just a page with some examples of it in various permutations. I liked your idea of something &#8220;schema like&#8221; to describe the structured data when its not obvious. Really, its a human developer that will be gluing this together, code generators will only do so much (and poorly) so just make it friendly, humane.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Darrel Miller</title>
		<link>http://bill.burkecentral.com/2009/05/21/to-wadl-or-not-to-wadl/#comment-2737</link>
		<dc:creator><![CDATA[Darrel Miller]]></dc:creator>
		<pubDate>Thu, 21 May 2009 20:36:42 +0000</pubDate>
		<guid isPermaLink="false">http://bill.burkecentral.com/?p=227#comment-2737</guid>
		<description><![CDATA[Sure, I put all sorts of meta data in my links.  It is documented in the specification of my media type.
HTTP describes my verbs, my media types describe my nouns and the relationships between my nouns.  What left is there for WADL to describe.]]></description>
		<content:encoded><![CDATA[<p>Sure, I put all sorts of meta data in my links.  It is documented in the specification of my media type.<br />
HTTP describes my verbs, my media types describe my nouns and the relationships between my nouns.  What left is there for WADL to describe.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Marc Hadley</title>
		<link>http://bill.burkecentral.com/2009/05/21/to-wadl-or-not-to-wadl/#comment-2734</link>
		<dc:creator><![CDATA[Marc Hadley]]></dc:creator>
		<pubDate>Thu, 21 May 2009 16:00:42 +0000</pubDate>
		<guid isPermaLink="false">http://bill.burkecentral.com/?p=227#comment-2734</guid>
		<description><![CDATA[Its not true that WADL ignores HATEOAS and links. See my recent blog entry for an example:

http://weblogs.java.net/blog/mhadley/archive/2009/04/hateoas_with_wa.html]]></description>
		<content:encoded><![CDATA[<p>Its not true that WADL ignores HATEOAS and links. See my recent blog entry for an example:</p>
<p><a href="http://weblogs.java.net/blog/mhadley/archive/2009/04/hateoas_with_wa.html" rel="nofollow">http://weblogs.java.net/blog/mhadley/archive/2009/04/hateoas_with_wa.html</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Craig McClanahan</title>
		<link>http://bill.burkecentral.com/2009/05/21/to-wadl-or-not-to-wadl/#comment-2733</link>
		<dc:creator><![CDATA[Craig McClanahan]]></dc:creator>
		<pubDate>Thu, 21 May 2009 14:40:42 +0000</pubDate>
		<guid isPermaLink="false">http://bill.burkecentral.com/?p=227#comment-2733</guid>
		<description><![CDATA[I happen to have asked Marc Hadley (JAX-RS spec lead, author of the WADL spec) about how WADL might be used to describe a REST service driven by self-discovered embedded links, rather than by URI template patterns.  His response was, basically, you could do this but need to establish a convention on how to figure out which elements are links.  His full comments were on his blog:

http://weblogs.java.net/blog/mhadley/archive/2009/04/hateoas_with_wa.html]]></description>
		<content:encoded><![CDATA[<p>I happen to have asked Marc Hadley (JAX-RS spec lead, author of the WADL spec) about how WADL might be used to describe a REST service driven by self-discovered embedded links, rather than by URI template patterns.  His response was, basically, you could do this but need to establish a convention on how to figure out which elements are links.  His full comments were on his blog:</p>
<p><a href="http://weblogs.java.net/blog/mhadley/archive/2009/04/hateoas_with_wa.html" rel="nofollow">http://weblogs.java.net/blog/mhadley/archive/2009/04/hateoas_with_wa.html</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: billburke</title>
		<link>http://bill.burkecentral.com/2009/05/21/to-wadl-or-not-to-wadl/#comment-2732</link>
		<dc:creator><![CDATA[billburke]]></dc:creator>
		<pubDate>Thu, 21 May 2009 14:11:27 +0000</pubDate>
		<guid isPermaLink="false">http://bill.burkecentral.com/?p=227#comment-2732</guid>
		<description><![CDATA[@Darrel

I agree to a degree.   You don&#039;t think that we need allow, and failure-type metadata within your links for update relationships?]]></description>
		<content:encoded><![CDATA[<p>@Darrel</p>
<p>I agree to a degree.   You don&#8217;t think that we need allow, and failure-type metadata within your links for update relationships?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Darrel Miller</title>
		<link>http://bill.burkecentral.com/2009/05/21/to-wadl-or-not-to-wadl/#comment-2730</link>
		<dc:creator><![CDATA[Darrel Miller]]></dc:creator>
		<pubDate>Thu, 21 May 2009 13:52:50 +0000</pubDate>
		<guid isPermaLink="false">http://bill.burkecentral.com/?p=227#comment-2730</guid>
		<description><![CDATA[If you properly describe the media types you are using then you do not need WADL.  All you need is the root url and the media type that url returns.

Imagine for a second that when building a RESTful interface you had a requirement that said all Urls must be just a GUID.  i.e. http://example.org/0A29FF9E-7F9C-4437-8B11-F424491E3931

I find that once you remove the crutch of the descriptive url, how to document RESTful interfaces becomes clearer.  I&#039;m not saying descriptive urls are a bad thing, in fact I believe the structure of the Url is very important to the server.  However, the client should not care what the url is.]]></description>
		<content:encoded><![CDATA[<p>If you properly describe the media types you are using then you do not need WADL.  All you need is the root url and the media type that url returns.</p>
<p>Imagine for a second that when building a RESTful interface you had a requirement that said all Urls must be just a GUID.  i.e. <a href="http://example.org/0A29FF9E-7F9C-4437-8B11-F424491E3931" rel="nofollow">http://example.org/0A29FF9E-7F9C-4437-8B11-F424491E3931</a></p>
<p>I find that once you remove the crutch of the descriptive url, how to document RESTful interfaces becomes clearer.  I&#8217;m not saying descriptive urls are a bad thing, in fact I believe the structure of the Url is very important to the server.  However, the client should not care what the url is.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: billburke</title>
		<link>http://bill.burkecentral.com/2009/05/21/to-wadl-or-not-to-wadl/#comment-2729</link>
		<dc:creator><![CDATA[billburke]]></dc:creator>
		<pubDate>Thu, 21 May 2009 13:24:51 +0000</pubDate>
		<guid isPermaLink="false">http://bill.burkecentral.com/?p=227#comment-2729</guid>
		<description><![CDATA[@Stefan:

Interesting, correct me if I&#039;m wrong, but the RFC does not solve the issues I&#039;ve presented here.  Also, I don&#039;t see how its that useful.  I would much rather have a well-formed link structure specific to the format I&#039;m transmitting (XML/JSON) than have to embed the suggested format within, lets say an attribute or element in XML and further reparse it.]]></description>
		<content:encoded><![CDATA[<p>@Stefan:</p>
<p>Interesting, correct me if I&#8217;m wrong, but the RFC does not solve the issues I&#8217;ve presented here.  Also, I don&#8217;t see how its that useful.  I would much rather have a well-formed link structure specific to the format I&#8217;m transmitting (XML/JSON) than have to embed the suggested format within, lets say an attribute or element in XML and further reparse it.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

