So, the answer to my question seems to be that none us know how to do it the way Fielding said it should be done, so none us know how to acheive a HATEOAS compliant RESTful API without violating Fielding's primary assertion regarding out-of-band data, and therefore making our app non-RESTful in so doing.
Everyone stridently believes they have this answer right, but we're all ignoring the fact that Roy Fielding says we are all wrong. He says we're all writing RPC's.
Roy Fielding: REST APIs must be hypertext-driven
"I am getting frustrated by the number of people calling any HTTP-based interface a REST API"
It boils down to the fact that we are not building the kind of apps that lend themselves to Roy's thesis on REST. Indeed, he believes the proposition that we would render our URI's as part of CDATA that includes the "method" or that the context of the URI would self-evidently provide it, like the FORM element does. He explicitly rails against the OpenSocialst REST API stating that it is not RESTful.
Here: “anchor elements with an href attribute create a hypertext link that, when selected, invokes a retrieval request (GET) on the URI corresponding to the CDATA-encoded href attribute.” Identifiers, methods, and media types are orthogonal concerns — methods are not given meaning by the media type. Instead, the media type tells the client either what method to use (e.g., anchor implies GET) or how to determine the method to use (e.g., form element says to look in method attribute). The client should already know what the methods mean (they are universal) and how to dereference a URI.
I tend to design JSON responses that provide this approach:
GET /account/12345 HTTP/1.1
... adding additional properties to the design as needed, but these are the basics.
I believe this allow the Client to be written to be RESTful, but in so doing I am using the Response Body, which Fielding says is not what he intended.