[aerogear-dev] REST-based API Versioning

[tolis emmanouilidis]

2014-08-29 15:09 GMT+03:00 Erik Jan de Wit <edewit at redhat.com>:

>
>
>
>>
>> Other option is to have 2 jax-rs classes, but to make that work they will
>> have to have 2 different paths. So you would have to ‘redirect’ / change
>> the path in the servlet filter based on the accept header. Which feels like
>> kinda of a hack to me.
>>
>
> While I like the above suggestion regarding the message format, couldn't
> we be still on the same path, and use some 'advanced' CDI injection
> mechanismn to inject a Version110SenderServiceImpl (or
> Version100ServiceImpl) ? Just curious
>
>
> Right with CDI qualifiers you could select a specific version of the same
> implementation see SenderServiceImpl for an example of this it has all the
> PushNotificationSenders and selects them based on the variantType.
>
> And because the json in this particular Endpoint is serialised into a
> Map<String, Object> we don’t even have to have 2 different versions of the
> SenderServiceImpl or have CDI qualifiers we ‘just’ need to have a Strategy
> based on version that converts the Map into a Message object.
>
> I must say this is probably the most simple solution to this specific API
> change so I’m +1 on this one.
>
> WDYT
>

Another option that might work out of the box would be to use the jax-rs
@Consumes annotation e.g @Consumes({"application/vnd.aerogear.v101+json"})
on the service endpoints.
So by making an abstract PushNotificationSenderEndpoint and and several
PushNotificationSenderEndpointV101, PushNotificationSenderEndpointV102 with
the right @Consumes annotation should work. I haven't tried it though


>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140829/3adb7c9b/attachment.html