On Thu, Aug 28, 2014 at 10:14 AM, Sebastien Blanc <scm.blanc@gmail.com> wrote:



On Thu, Aug 28, 2014 at 9:29 AM, Daniel Bevenius <daniel.bevenius@gmail.com> wrote:
>If we go for the accept header and the consumer don't provide it, what do we do ? Return an error or use implicitly the latest version ?
Perhaps we can return the current version to not break any existing clients. New clients will need to provide an explicit version.
Why not but for how long do we return the "old" version by default ? (cf my questions around deprecation)  

yep - I am for that: looks like I forgot, and I think we had that on our face2face: no version == 1.0.0 (old)

-M
 


On 28 August 2014 09:25, Sebastien Blanc <scm.blanc@gmail.com> wrote:
Some questions : 

* If we go for the accept header and the consumer don't provide it, what do we do ? Return an error or use implicitly the latest version ?
* What will be our deprecation policy ? Do we want keep maintaining all the versions forever or let's say for 1.1 we still provide 1.0 and for 2.0 we drop 1.0 ? 

About the implementation :
* I like the suggested CDI solution, if possible.
* Erik also mentionned OSGI and I'm -9999^99 to introduce that techno 

Sebi
ps : I just read this blog post and it's really interesting : http://apiux.com/2013/05/14/api-versioning/



On Thu, Aug 28, 2014 at 8:07 AM, Daniel Bevenius <daniel.bevenius@gmail.com> wrote:
+1 For using the Accept header to specify the version in the media type.


On 28 August 2014 07:50, Matthias Wessendorf <matzew@apache.org> wrote:
Hello,

for the 1.1.x (master) we are potentially doing some changes on the Sender-API (see [1]).

However, for backwards compatibility we need to think about API versioning.

For REST APIs there are (IMO) two options:
* accept header
* URIs

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?


Besides the what (headers vs. URI), I think we should think about possible implementations, to switch different versions.

Not sure, but wouldn't it be possible to inject an annotated SenderService into the RESTful endpoint, based on header values ? 
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

Any thoughts ? 

-Matthias



--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf