<span id="mailbox-conversation">I think this is something to fix at our SDKs, and think about the legacy, that's the price to pay.<div><br></div>
<div>The easy solution is to defaults to 1.0.0, but it doesn't seem correct.</div></span><div class="mailbox_signature">—<br>abstractj <br>PGP: 0x84DC9914 </div>
<br><br><div class="gmail_quote"><p>On Thu, Aug 28, 2014 at 10:18 AM, Matthias Wessendorf <span dir="ltr">&lt;<a href="mailto:matzew@apache.org" target="_blank">matzew@apache.org</a>&gt;</span> wrote:<br></p><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div dir="ltr">the problem is... our 1.0.0 SDKs do not specify a version :-)<div>so, they would than talk to the latest greatest, that does not work.</div>
<div><br></div>
<div>We need to have that in mind, when planing this.</div>
<div><br></div>
<div><br></div>
</div>
<div class="gmail_extra">
<br><br><div class="gmail_quote">On Thu, Aug 28, 2014 at 2:39 PM, Lucas Holmquist <span dir="ltr">&lt;<a href="mailto:lholmqui@redhat.com">lholmqui@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 style="word-wrap:break-word">+1 on Accept headers and also using the latest and greatest if no version is specified/<div>
<br></div>
<div>i believe this is what github also does<div><div class="h5">
<br><div>
<div>On Aug 28, 2014, at 4:36 AM, Bruno Oliveira &lt;<a href="mailto:bruno@abstractj.org">bruno@abstractj.org</a>&gt; wrote:</div>
<br><blockquote type="cite"><div style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
On 2014-08-28, Matthias Wessendorf wrote:<br><blockquote type="cite">On Thu, Aug 28, 2014 at 10:14 AM, Sebastien Blanc &lt;<a href="mailto:scm.blanc@gmail.com">scm.blanc@gmail.com</a>&gt;<br>wrote:<br><br><blockquote type="cite">
<br><br><br>On Thu, Aug 28, 2014 at 9:29 AM, Daniel Bevenius &lt;<br><a href="mailto:daniel.bevenius@gmail.com">daniel.bevenius@gmail.com</a>&gt; wrote:<br><br><blockquote type="cite">
<blockquote type="cite">If we go for the accept header and the consumer don't provide it, what<br></blockquote>do we do ? Return an error or use implicitly the latest version ?<br>Perhaps we can return the current version to not break any existing<br>
clients. New clients will need to provide an explicit version.<br><br></blockquote>Why not but for how long do we return the "old" version by default ? (cf<br>my questions around deprecation)<br><br></blockquote>
<br>yep - I am for that: looks like I forgot, and I think we had that on our<br>face2face: no version == 1.0.0 (old)<br></blockquote>
<br>I vote for return the latest, instead of something old. And specify old<br>versions if you want to.<br><br><blockquote type="cite">
<br>-M<br><br><br><blockquote type="cite">
<br><blockquote type="cite">
<br>On 28 August 2014 09:25, Sebastien Blanc &lt;<a href="mailto:scm.blanc@gmail.com">scm.blanc@gmail.com</a>&gt; wrote:<br><br><blockquote type="cite">Some questions :<br><br>* If we go for the accept header and the consumer don't provide it, what<br>do we do ? Return an error or use implicitly the latest version ?<br>* What will be our deprecation policy ? Do we want keep maintaining all<br>
the versions forever or let's say for 1.1 we still provide 1.0 and for 2.0<br>we drop 1.0 ?<br><br>About the implementation :<br>* I like the suggested CDI solution, if possible.<br>* Erik also mentionned OSGI and I'm -9999^99 to introduce that techno<br><br>Sebi<br>ps : I just read this blog post and it's really interesting :<br><a href="http://apiux.com/2013/05/14/api-versioning/">http://apiux.com/2013/05/14/api-versioning/</a><br><br><br><br>On Thu, Aug 28, 2014 at 8:07 AM, Daniel Bevenius &lt;<br><a href="mailto:daniel.bevenius@gmail.com">daniel.bevenius@gmail.com</a>&gt; wrote:<br><br><blockquote type="cite">+1 For using the Accept header to specify the version in the media type.<br><br><br>On 28 August 2014 07:50, Matthias Wessendorf &lt;<a href="mailto:matzew@apache.org">matzew@apache.org</a>&gt; wrote:<br><br><blockquote type="cite">Hello,<br><br>for the 1.1.x (master) we are potentially doing some changes on the<br>Sender-API (see [1]).<br><br>However, for backwards compatibility we need to think about API<br>versioning.<br><br>For REST APIs there are (IMO) two options:<br>* accept header<br>* URIs<br><br>On our Face2Face meeting we briefly talked about this and I think the<br>"accept header" solution was the one that had most fans. I think QMX added<br>
that it is better for migration. One thing we were not clear on (I think):<br>What are HATEOS defined semantics?<br><br><br>Besides the what (headers vs. URI), I think we should think about<br>possible implementations, to switch different versions.<br><br>Not sure, but wouldn't it be possible to inject an annotated<br>SenderService into the RESTful endpoint, based on header values ?<br>We could have a default impl (version 1.0.0) and an alternate one,<br>that is injected if the accept header indicate API version 1.1<br><br>Any thoughts ?<br><br>-Matthias<br><br><br>[1]<br><a href="http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008881.html">http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008881.html</a><br><br>--<br>Matthias Wessendorf<br><br>blog: <a href="http://matthiaswessendorf.wordpress.com/">http://matthiaswessendorf.wordpress.com/</a><br>sessions: <a href="http://www.slideshare.net/mwessendorf">http://www.slideshare.net/mwessendorf</a><br>
twitter: <a href="http://twitter.com/mwessendorf">http://twitter.com/mwessendorf</a><br><br>_______________________________________________<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">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br><br></blockquote>
<br><br>_______________________________________________<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">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br><br></blockquote>
<br><br>_______________________________________________<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">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br><br></blockquote>
<br><br>_______________________________________________<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">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br><br></blockquote>
<br><br>_______________________________________________<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">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br><br></blockquote>
<br><br><br>--<br>Matthias Wessendorf<br><br>blog: <a href="http://matthiaswessendorf.wordpress.com/">http://matthiaswessendorf.wordpress.com/</a><br>sessions: <a href="http://www.slideshare.net/mwessendorf">http://www.slideshare.net/mwessendorf</a><br>
twitter: <a href="http://twitter.com/mwessendorf">http://twitter.com/mwessendorf</a><br></blockquote>
<br><blockquote type="cite">_______________________________________________<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">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br></blockquote>
<br><br>--<br><br>abstractj<br>PGP: 0x84DC9914<br>_______________________________________________<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">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a>
</div></blockquote>
</div>
<br></div></div>
</div>
</div>
<br>_______________________________________________<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">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br></blockquote>
</div>
<br><br clear="all"><div><br></div>-- <br>Matthias Wessendorf <br><br>blog: <a href="http://matthiaswessendorf.wordpress.com/">http://matthiaswessendorf.wordpress.com/</a><br>sessions: <a href="http://www.slideshare.net/mwessendorf">http://www.slideshare.net/mwessendorf</a><br>
twitter: <a href="http://twitter.com/mwessendorf">http://twitter.com/mwessendorf</a>
</div>
</blockquote></div><br>