Question

In Zend Framework 2, content negotiation happens on the view layer and I am pretty happy with it. An example in my controller:

public function viewAction()
{
    $id   = $this->params('id');
    $user = $this->getRepository()->findUser();

    return new ViewModel(array(
        'user' => $user,
    ));
}

This either renders the view.phtml template to return html or it converts the user object to a JSON response. A so-called view strategy determines how to render the response based on the request.

“REST” Application Flow in my webapp

This type of content negotiation works pretty good for many use cases:

1. /user or indexAction() returns an array of users => html of JSON possible;
2. /user/1 or viewAction() returns user object => html or JSON possible (example from above);
3. /user/1/update or updateAction() returns a html form. A POST to this url returns html or JSON when errors are present. Or on success it redirects to viewAction() and thus returns the new version of the user => html and JSON again possible;
4. /user/create or createAction() returns a html form. A POST to this url returns html or JSON when errors are present. Or on success it redirects to viewAction() for the just created user => html and JSON again possible

My Question

There are a few use cases where the content negotiation is sort-of “required” in the controller layer. I am not sure if I overlook some possibilities: are there options I can use in for example the following cases?

1. Delete a user: POST to the /user/1/delete. In case of a html view, you will be redirected to the list of users (where the deleted user is now missing). In case you want a JSON response, you want to return 200 OK and a JSON object with a message the delete was successful.
2. Post a comment to a blog article. In case of a html view, you will be redirected to the post where you see your comment is appended. In case you ask for a JSON response, you want to return 200 OK and a JSON object with the comment you just placed.

My goal would be to not replicate the content negotiation already present in the view layer. It would also make my controllers more fat, since I have now two possible responses (JSON vs html) but that might not be the only case. If I later want to support XML or another format, I have for every action switches for those response types.

Answer 1

Interestingly, we’re looking currently at moving the content negotiation aspect out of the view strategy listeners, and instead into controller plugins. The rationale is largely as you note — it’s the controller’s job to match an incoming request to the appropriate model(s) and view. As such, yes, I think you’re on the right track — and likely the tools being developed now for 2.1 will fit the methodologies you have quite nicely. (See https://github.com/zendframework/zf2/pull/2615 for details.)