<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 28, 2014 at 10:39 AM, Erik Jan de Wit <span dir="ltr">&lt;<a href="mailto:edewit@redhat.com" target="_blank">edewit@redhat.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">&gt;<br>
&gt; On our Face2Face meeting we briefly talked about this and I think the &quot;accept header&quot; solution was the one that had most fans. I think QMX added that it is better for migration. One thing we were not clear on (I think): What are HATEOS defined semantics?<br>

&gt;<br>
</div>+1 for accept header<br>
<div class="">&gt;<br>
&gt; Besides the what (headers vs. URI), I think we should think about possible implementations, to switch different versions.<br>
&gt;<br>
&gt; Not sure, but wouldn&#39;t it be possible to inject an annotated SenderService into the RESTful endpoint, based on header values ?<br>
&gt; We could have a default impl (version 1.0.0) and an alternate one, that is injected if the accept header indicate API version 1.1<br>
<br>
</div>Don’t know of anything that can do something like that automatically and rest easy doesn’t provide anything for versioning. I would propose to keep it simple and let UPS internally use the latest version and provide something like a servlet filter that converts old calls to the new API or dispatches to another rest end point<br>

<br>
WDYT<br></blockquote><div>+1 I like the Servlet Filter approach</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
</div></div></blockquote></div><br></div></div>