I've been involved in a client project on basis of fairly standard crud-sf3-stuff. The complexity of the project exists inside the frontend twig/js-code. As a next step there has to be a standards-compliant API and was thinking of using the api-platform. It's not possible, due to time-constraints, to rewrite the frontend-portions of the code yet.
While I was thinking, it came to my mind, that 90% of the controllers are simply crud and would be duplicated by the to-be-written-API-implementation. In the process of thinking, I had the Idea to use the existing twig-templates as only one another "format" of the api to reduce the amount of code in the project massively.
If I'm not entirely wrong, you should only have to write a kind "twig-serializer", do some kind of url-to-twig-mapping and render it as result for content-type html. Maybe one could add some options to the bundle to map api-routes to twig-templates and/or configure the mapping via annotations inside the entity...
So my basic questions are: do you know of any efforts in this direction? Is my idea complete nonsense because of any errors in my thinking?
I never tried it but it should already work without needing to modify the bundle. A class implementing the EncoderInterface of the serializer passing the normalized array to a Twig template (by injecting the twig service in the encoder) should do the trick.
That's what I was thinking about. One could also try to build dynamic forms out of the mapping definitions for post-actions. I'm surprised that nobody did some work in this direction, because, at least in my opinion, it would be a killer-feature which could possibly reduce the boilerplate-code in many projects massively. @dunglas, thanks for your awesome work and the fast response!
API Platform is about a REST(ful) web API. Any kind of HTML forms builder (like Symfony Form) is mixing the frontend and the backend, so should never be supported here...
@teohhanhui I totally agree, but it's okish in a private app or in a separate community bundle.