On Thu, Aug 28, 2014 at 9:25 AM, Sebastien Blanc <scm.blanc(a)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
that OSGI suggestion was a joke ;-)
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(a)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(a)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
>>
>>
>> [1]
>>
http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008881.html
>>
>> --
>> Matthias Wessendorf
>>
>> blog:
http://matthiaswessendorf.wordpress.com/
>> sessions:
http://www.slideshare.net/mwessendorf
>> twitter:
http://twitter.com/mwessendorf
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)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