As far as I can tell, that&#x27;s pretty much all you&#x27;ve got. Given the heavy concentration this library seems to place on converting static navigation to dynamic, my surmise is that, instead of responding to a navigation link with an entire HTML document, it just responds with the content that document would contain in the response object&#x27;s &quot;body&quot; member, with content fragments organized by the ID of the element they&#x27;re meant to populate. View changes seem to be supported by sending the appropriate template fragments in the &quot;head&quot;, &quot;title&quot;, and optionally &quot;foot&quot; members of the response JSON object.<p>More complex state transitions such as form submissions appear to be provided for in the second argument of the spf.navigate method, which can take an object including a POST method specification and the corresponding data. It looks like that&#x27;s about all the library provides in terms of request flexibility; per the code, setting custom request headers on navigation requests is definitely unavailable, but it doesn&#x27;t do anything to override the default behavior by which XHR passes on e.g. Authorization headers already set by client code, so (in conjunction with e.g. OAuth) you&#x27;d be able to identify and authenticate the user making the request. I guess the idea is that, for the purpose the library&#x27;s meant to answer, what it provides in the URI is just about all the information the server should need on what content to include in the response.