I think it's pretty common to see query params used in this way to control the representation you get back. I'd probably not stir up the nest of REST vipers by creating a generic mechanism for overriding http request headers. But instead just have a simple 'format' query param: <Url type="application/rss+xml" template="http://viaf.org/search?query=cql.any+all+%22{searchTerms}%22+&maximumRecords=100&startRecord={startIndex}&sortKeys=holdingscount&format=rss"/> Ideally clients would see the type of 'application/rss+xml' on the Url template and use it in the Accept header of the request, and your server side app could use the Accept to figure out that it can send back an application/rss+xml representation. But clients typically don't. That's why Twitter and others allow you to indicate the response format in the url [1]. But as Subbu mentions in that post, implementing content negotiation on the server side for well behaved clients is a good way to help things get better. //Ed [1] http://www.subbu.org/blog/2008/04/content-negotiation-is-not-broken