mwvaughn
commented
2 years ago This is harder than it seems. The best recommendation is from StackOverflow, where it is recommended to implement a subclass of fastAPI's Response class and use that as the response_class for routes where pretty printing is required. Unfortunately, while this works in that it returns pretty-printed JSON, it has the side effect of breaking the OpenAPI generation. Endpoints that adopt this approach are all interpreted to return content application/json (correct) but with a response model of string rather than a JSON structure reflecting the data model for object(s) returned by the endpoint.
The FastAPI framework returns compact JSON by default. This is good for processing by machine, and saves transfer bandwidth by eliminating spaces, but is difficult for human consumers of the API to use. Instead, we should provide an option to return pretty JSON. This could be done on a per-request basis via a special URL parameter or request header or at the service level as a configuration variable. The former solution would mix in what is essentially a display variable with the variables controlling data access. The latter solution is pretty coarse-grained, but has the benefit of consistency.