frameworkers/furnace — Issue #3: Implement response-type detection via the HTTP 'accept' header
Author: andrewfhart
Created: 2012-02-06 05:35:26+00:00
State: open

One of the design goals behind Furnace was to make it uniformly easy to build and return responses in various forms and formats (HTML, JSON, XML, RSS, etc). Because of a strict separation between logic and presentation in Furnace, it should also be possible use the same controller handler logic to return various response types. A recurring point of discussion has been how best to let the framework know what type of response should be generated for a particular request.

At the moment, the following two methods are supported:

* Response type is explicitly declared as part of the route definition. By default, responses are of type 'text/html' and processed by the HtmlResponse class. To change this behavior for a given route, developers simply add `type => 'application/json'` or something similar to the specific route definition. This works well for cases in which only one response type is ever expected.

* To provide a more flexible way to dynamically select the desired response type, Furnace also supports appending the special sequence `/>` to the end of the request url, followed by the desired content type. For example to view `http://site//foo/bar` as JSON, one would request `http://site/foo/bar/>json` (The syntax for this was borrowed from the folks behind http://broadbandmap.gov). This works well for allowing users to dynamically request specific content types.

While the two cases above cover most usage scenarios, the introduction of the non-standard `/>` syntax is at best a hack. The HTTP Accept header (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html) provides a standard for requesting specific response types which should also be supported. In order of precedence, then, type detection should follow the path of:

1) Is the response type explicitly defined in the definition for the matching route? Yes: use it, No: continue
2) Is the `/>format` sequence present at the end of the request url? Yes: parse and use it, No: continue
3) Is the HTTP Accept header present? Yes: parse and use it, No: continue
4) Default to 'text/html'