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 

ps : I just read this blog post and it's really interesting :

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

On 28 August 2014 07:50, Matthias Wessendorf <> wrote:

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 Wessendorf


aerogear-dev mailing list

aerogear-dev mailing list