Support of API versioning

[borisguery]

API versioning is a requirement when working with API, it gives control over the Response representation and allow improvement of both backend and clients without breaking things.

However, it is a tricky question, and there are best practices as well as real-life use case.

Therefore, there may be no "correct solution" for this.

I may recommend a ApiVersionStrategy utility, implementing the Strategy pattern to decide how to work with version in an uniform way.

The ApiVersionStrategy are free to be implemented by end-developers but we may provide a basic subset of common case like uri versioning, Accept versioning, etc.

The ApiVersionStrategy would generate an ApiConstraint which would be available to in a uniform and consistent way to decide of the implementation.

Depending on the rest of the implementation it may takes place in the Routing module.

[bakura10]

I have too admit I'm not an expert about this. But ocramius' idea was to simply set the serializer according to the version. So basically, in your mapping, you could do something like this:

/**
 * @Rest\Decoders({@REST\Decoder(name="application/vnd-v1", class="Application\User\SerializerV1")},
*  @REST\Decoder(name="application/vnd-v2", class="Application\User\SerializerV2"})
class User

[bakura10]

This is too complicated to do correctly and I decided to get rid of this feature for now. We'll delay that for later.

[bakura10]

Hi,

I know this is old thread, but the complete rewrite of ZfrRest (#187), include an initial support for versioning through templates. You can have a look at how this is addressed for instance: https://github.com/zf-fr/zfr-rest/blob/refactor/docs/03.%20View%20layer.md#reuse-template-for-multiple-versions

I keep that open though as full support is not yet here.