@lsmith77 any news here ?

no .. basically the notes in the PR description are still valid, but its a fair bit of work and i haven't been able to work on it further ..

Needs to be updated to support new Routing architecture. But it should be fairly easy as new arch is freaking clean :-D

@lsmith77 will you add object versioning from JMSSerializerBundle doc link ?

this PR is currently idling unfortunately. but yes thats the idea and we should support this right now already. aka allow setting the serializer version via the View class.

regards,
Lukas

On 22.03.2012, at 10:43, Oleg Zinchenko reply@reply.github.com wrote:

@lsmith77 will you add object versioning from JMSSerializerBundle doc link ?

---

Reply to this email directly or view it on GitHub:
#136 (comment)

see also https://github.com/winmillwill/BadFaith

Hi, any news on this ? (maybe after yesterday's REST talk at symfony live ?)
What needs to be done ?

no .. there is no progress here aside from some general improvements to better integrate JMSSerializerBundle inside the View class. that BadFaith lib is however slowly, but surely, maturing.

Any way I can help scoot this along? What's the block exactly?

the key thing is improving the support fir mime types inside the routing. this is the basis for mime type based versioning. see the link to the BadFaith lib. it seems like Flow3 1.1 will also feature a solution for Accept header negotiation which could serve as an inspiration.

Any chance we could look at URI versioning for the time being since that will likely be desired by many users?

personally i am not too interested to work on that. also i dont think doing url based versioning is so hard to do right now already since for that mainly all you need is url pattern based routing which already exists and then you just point to different controllers leveraging inheritance where needed.

here is what the flow3 guys did for routing with content type negotiation:
https://review.typo3.org/#/c/11683/1

see also symfony/symfony#5711

any news

nope. symfony/symfony#5711 is stalled which seemed like the most promising initiative for a while.

The version need to be also configured in the SerializationContext object.

API versioning still out in the cold?

yes .. there is some progress in terms of a better content negotiation lib with https://github.com/willdurand/Negotiation but now the big task is left of integrating it within the Routing system

/cc @willdurand

Yup. Don't really know how to that though.

I did API versioning once using different routes /v1/..., /v2/... but it is not "cool". What we want is to leverage the Accept header but then what? How do we organize controllers and actions?

• A sub-namespace?
• A specific controller name mapped to a version somewhere?
• Something else?

I thought about using a proxy controller that would forward the request to the right controller.

Example: the routing uses Controller\UserController. In this controller, if the version is:

• v1 then we use Controller\V1\UserController
• v2 then we use Controller\V2\UserController

we could maybe do a simple solution that will likely work in more than 80% of the cases. we could have a very early listener that looks at the media type and if it finds there is only one then we attempt to extract a version via a convention (optionally via some callback). this version is set as a request attribute and can therefore be checked via a route requirement.

Ah I am stupid. Yes, using the routing layer makes sense.

Actually @meandmymonkey and I thought about a similar approach lately using a listener which does negotiation before the routing using https://github.com/willdurand/Negotiation and setting request attributes.

anyone want to try and implement it? :)

It does not work. UrlMatcher don't use attributes.. I think we need a RequestMatcher, but don't know who to inject it into the RouterListener...

what about using the default then?

See this: willdurand/BazingaRestExtraBundle@5880f3e

Which default?

So, the UrlMatcher is not able to check attributes other than _method and _scheme. It is not able to check "custom" attributes. That is why we need a RequestMatcher but it is not injected by default in the RouterListener, and I am not sure to know how to do that the right way.

i was thinking the route defaults .. but they obviously don't exist yet .. so nevermind.
btw .. do you really think it makes sense to add this feature to that Bundle rather than adding it here?

@Tobion .. maybe you can help here?

do you really think it makes sense to add this feature to that Bundle rather than adding it here?

Not at all! I just hacked into this bundle as it does not pollute that one, and it made things easier in my test project. This feature MUST be part of the FOSRestBundle.

So now that we know that this solution does not work, we need to find a new idea :p

Should 2 different versions go to 2 different controllers?

Shouldn't they both go to the same controller that has something like this:

$serializer->serialize($object, 'json', SerializationContext::create()->setVersion($versionFromAcceptHeader));

?

@kbond you could do more stuff than changing the "view" of your data between two given versions.

@kbond https://github.com/kbond Absolutely... two different versions of
an API could do very different things, despite identical endpoints.

On Fri, Aug 16, 2013 at 11:43 AM, William Durand
notifications@github.comwrote:

@kbond https://github.com/kbond you could do more stuff than changing
the "view" of your data between two given versions.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/136#issuecomment-22743064
.

Is there anything stable already released about a dynamic versioning support with FosRestBundle and JMSSerializer (for Until and Since annotation support)?