Support REST controller invalidation

[ddeboer]

Add a controller annotation and YML configuration option that invalidate all methods in a controller when they and their routes names follow a convention, such as the of the FOSRestBundle.

[dbu]

@lsmith77 do you have inputs for this idea? sounds like a cool RAD way of doing things.

[lsmith77]

can you elaborate a bit more on how this is supposed to work?

[ddeboer]

Maybe have an annotation @EnableInvalidation annotation that when added to a controller class, would enable cache invalidation for all controllers in it (caching headers themselves could be set with SensioFrameworkExtraBundle's @Cache annotation). Each unsafe request to one of the controllers then automatically invalidates the cache for that controller's safe equivalent. So:

POST /things invalidates GET /things
PUT/DELETE /things/123 invalidates GET /things/123

etc.

For determining invalidation paths, we could:

• look at route names, which works with predictably named routes (such as FOSRestBundle's automatic route generation)
• look at the paths, which only works with RESTful paths.

[ddeboer]

The only problem I see here is that we would need to check whether the route actually exists: so if put_article triggers an invalidation, get_articles should not be invalidated if that route didn’t exist. Or is it now safe to use getRouteCollection() for this?

[stof]

Or is it now safe to use getRouteCollection() for this?

no it is not. getRouteCollection triggers the route loading, which is not a good idea in production (unless you build your own cache on top of it to avoid redoing it many times of course)

[dbu]

we face the same problem with the route collection in #161 - what would be the clean way to do such things?

[stof]

@dbu Building a service which extracts the informations from the RouteCollection and then caches them. You can look at the way FOSRestBundle does it