RequestParser and LinksBuilder rework

Some recent PRs and Issues (#928, #951, and a few issues related to links generation) have had me thinking about the deficiencies in the RequestParser architecture.

Request parsing is largely hidden behind the RequestParser which takes JSONAPI formatted requests and turns them into Operations which are then executed by a resource specific Processor (or the default Processor). A RequestParser is instantiated by the controller but beyond that it's out of the users control without monkey patching the RequestParser.

Instead of having a custom action parsed differently from the standard actions I'd like to rework the request parsing stage so custom actions would be handled in the same way as the standard defined actions.

I'm proposing we move the RequestParser logic in the controller to allow easy addition of custom actions and overriding of the existing actions. This could be done in a series of modules with core behavior in one and actions for V1 and the new Operations spec (#951) in another.

In addition the LinksBuilder generates links for routes/actions which may not exist. I'd like to tie the link building to the routes supported by the controller. The changes to support the custom actions will need changes to the links generation so this seems like a good time to tackle this too.

Thoughts?

El issue menciona RequestParser, la lógica del controlador, LinksBuilder, las acciones personalizadas y la especificación de Operations en #951, pero no indica archivos ni tests. Empieza trazando cómo el controlador instancia RequestParser y cómo LinksBuilder deriva las rutas. Se considera terminado cuando las acciones personalizadas y estándar comparten la ruta de parsing revisada y los enlaces generados solo apuntan a rutas compatibles con el controlador.