On 2014-08-28, Matthias Wessendorf wrote:
On Thu, Aug 28, 2014 at 10:14 AM, Sebastien Blanc
<scm.blanc(a)gmail.com>
wrote:
>
>
>
> On Thu, Aug 28, 2014 at 9:29 AM, Daniel Bevenius <
> daniel.bevenius(a)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)
I vote for return the latest, instead of something old. And specify old
versions if you want to.
-M
>
>>
>> On 28 August 2014 09:25, 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
>>>
>>> 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
>>>
>>
>>
>> _______________________________________________
>> 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
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
abstractj
PGP: 0x84DC9914