<?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/"
		>
<channel>
	<title>Comments on: Jersey Going Astray?</title>
	<atom:link href="http://www.nordsc.com/blog/?feed=rss2&#038;p=278" rel="self" type="application/rss+xml" />
	<link>http://www.nordsc.com/blog/?p=278</link>
	<description></description>
	<lastBuildDate>Mon, 05 Jul 2010 15:38:14 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Guilherme Silveira</title>
		<link>http://www.nordsc.com/blog/?p=278#comment-60</link>
		<dc:creator>Guilherme Silveira</dc:creator>
		<pubDate>Wed, 10 Feb 2010 18:37:50 +0000</pubDate>
		<guid isPermaLink="false">http://www.nordsc.com/blog/?p=278#comment-60</guid>
		<description>Hello Jan,

Great comments. I can say that nowadays its much clearer in my mind why such approach should not be the one for rest frameworks.

I believe the link support approach implemented by Jersey started when Restfulie released a no-JSR compatible rest approach. As you mentioned, the first Restfulie example also made available a &quot;pay&quot; method *if* the representation contains a pay link. Later we realized that all relations should be treated as, well, relations. A &quot;payment&quot; relation (as specified by atom if my representation is an atom one), allows me to pay without any problems. A related items relation that points to another atom collection allows items to be POSTED in order to add items to it and so on... everything because the media type defined the semantics of such relations and therefore they are well understood.

I also believe the JSR should not follow the path of early binding and some other decisions as Ive pointed throughout some posts in my blog. Maybe with time passing we can change it? The problem is, or is not, that its a JSR, or a too early specified JSR?

Regards</description>
		<content:encoded><![CDATA[<p>Hello Jan,</p>
<p>Great comments. I can say that nowadays its much clearer in my mind why such approach should not be the one for rest frameworks.</p>
<p>I believe the link support approach implemented by Jersey started when Restfulie released a no-JSR compatible rest approach. As you mentioned, the first Restfulie example also made available a &#8220;pay&#8221; method *if* the representation contains a pay link. Later we realized that all relations should be treated as, well, relations. A &#8220;payment&#8221; relation (as specified by atom if my representation is an atom one), allows me to pay without any problems. A related items relation that points to another atom collection allows items to be POSTED in order to add items to it and so on&#8230; everything because the media type defined the semantics of such relations and therefore they are well understood.</p>
<p>I also believe the JSR should not follow the path of early binding and some other decisions as Ive pointed throughout some posts in my blog. Maybe with time passing we can change it? The problem is, or is not, that its a JSR, or a too early specified JSR?</p>
<p>Regards</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Paul Sandoz</title>
		<link>http://www.nordsc.com/blog/?p=278#comment-56</link>
		<dc:creator>Paul Sandoz</dc:creator>
		<pubDate>Wed, 10 Feb 2010 10:24:58 +0000</pubDate>
		<guid isPermaLink="false">http://www.nordsc.com/blog/?p=278#comment-56</guid>
		<description>Criticism is good. We want a good debate about the best way forward, both on the server-side and the client-side proxy. Which is why we chose to be very open about this and why Santiago clearly states: 

http://weblogs.java.net/blog/spericas/archive/2010/02/09/exploring-hypermedia-support-jersey

&quot;Note that the proposed API is still experimental and will possibly evolve in unforeseen (and incompatible) ways. Your feedback will be extremely valuable in shaping future versions of this API.&quot;</description>
		<content:encoded><![CDATA[<p>Criticism is good. We want a good debate about the best way forward, both on the server-side and the client-side proxy. Which is why we chose to be very open about this and why Santiago clearly states: </p>
<p><a href="http://weblogs.java.net/blog/spericas/archive/2010/02/09/exploring-hypermedia-support-jersey" rel="nofollow">http://weblogs.java.net/blog/spericas/archive/2010/02/09/exploring-hypermedia-support-jersey</a></p>
<p>&#8220;Note that the proposed API is still experimental and will possibly evolve in unforeseen (and incompatible) ways. Your feedback will be extremely valuable in shaping future versions of this API.&#8221;</p>
]]></content:encoded>
	</item>
</channel>
</rss>
