A Views Layer for Keystone

Keystone has an unusual way of rendering objects that are used in responses.

1) The objects are returned directly from the driver layer, some links injected at the controller and then returned to the user. This means the backend driver has full control over the representation of objects. This is really bad form and doesn't help for people who are implementing their own drivers because they are capable of accidently polluting the output and then relying on it.

2) The Controllers handle the links generation - however there are more controllers than types. For example Projects are handled from the regular projects urls, auth urls, catalog urls and federation urls. To make this rendering work you then need to import the base projects controller into all these other places so that they can work. In some cases this is done as a subclass which makes this harder. These could each be individual views that know how to render a project and then used where appropriate.

3) Because of the direct link from backend to user representation it imposes a v3 representation on the objects in the database. These two things should not be equivalent. There is information that should be added and removed from objects before they are saved to the database and this direct representation means you have to have a lot of care. This also means there are a number of places that are doing a v3_to_v2 conversion - which should really just be 2 different representations of the same model.

4) Again because of the direct representation it is really difficult to audit the expected output of a resource. Often the authoritative source of what a resource looks like is the SQL Alchemy resource.

5) If we go down the microversion path this negotiation gets complicated and all mixed up with the representation layer.

We should remove response rendering from the controllers in favour of a views layer that is purely about rendering. This is a very standard pattern in web services.