<div dir="ltr"><div>Hello,</div><div><br></div><div>for the 1.1.x (master) we are potentially doing some changes on the Sender-API (see [1]).</div><div><br></div><div>However, for backwards compatibility we need to think about API versioning.</div>
<div><br></div><div>For REST APIs there are (IMO) two options:</div><div>* accept header</div><div>* URIs</div><div><br></div><div>On our Face2Face meeting we briefly talked about this and I think the "accept header" 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?</div>
<div><br></div><div><br></div><div>Besides the what (headers vs. URI), I think we should think about possible implementations, to switch different versions.</div><div><br></div><div>Not sure, but wouldn't it be possible to inject an annotated SenderService into the RESTful endpoint, based on header values ? </div>
<div>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</div><div><br></div><div>Any thoughts ? </div><div><br></div><div>-Matthias</div><div>
<br></div><div><br></div><div>[1] <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></div><div><br></div>-- <br>Matthias Wessendorf <br>
<br>blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a>
</div>