API related base controller.

[WanWizard]

Making sure content headers are set and data is formatted correctly.

[sagikazarmark]

I would be careful with base controllers. I've had a hard time with combining Model behaviours in Fuel 1.x

I don't say we shouldn't do it, but we have to be careful.

[WanWizard]

@stevewest For me this is related to decoupling logic from presentation.

If we design a controller that always returns a data object, rendering that object to for example a JSON response can be done externally. I think default rendering information can be added to the object when it is created based on info from the configuration and/or the request. The data object should have methods to allow the controller to overrule these settings.

[emlynwest]

@WanWizard Sounds sensible to me. I think leaving this issue here would be best for now, until the data/display logic is decoupled.

[WanWizard]

Perhaps that "data object" should be a generic Response object.

We could create Renderer classes, and register those. The Response could then use these Renderers when it needs to produce output, based on either a renderer selection made by the controller, or by determination logic from the Request (i.e. if JSON is requested, return JSON).

It could also take the return status into account, i.e. if the Response object has a status 404, and the determined format is JSON, return a 404 message in JSON format (layout to be determined by the Renderer).

[emlynwest]

Drifting a bit from this issue's subject, but yep, I have plans along those lines for this.

[WanWizard]

👍