There are two, somewhat orthogonal questions, here:
- Should an API provide documentation on its outputs as well its inputs?
- How should that documentation be provided in the context of a RESTful design?
The answer to question 1 is a resounding "yes": any client needs to have knowledge somewhere of what information it can retrieve from an API, or the API has no practical use. If I want to display some products results from your API, I absolutely need to know whether they have a description, an image URL, etc, and how to extract those from a particular representation.
The answer to question 2 is much more subtle. In a true REST design, there are no defined URLs, and so there can be no defined responses from sending requests to those URLs. Instead, there are defined content types, and defined relationship types.
Content types are fairly straight-forward to think about: think about XML or JSON schemas for entities like "Product" or "SearchResultList", but then add the semantics (meaning) as well as the syntax (structure and format). All the requests and responses used by the API should use documented content types.
Relationship types are less easily understood, and the part that few "RESTish" APIs actually implement. I will also probably explain it really badly, so take everything in this paragraph with a grain of salt, and read up on "HATEOAS" if you're interested. The idea is that as part of a content type like "SearchResultList" would be elements which are simply links to other API end-points, each labelled with an identifier. Those identifiers would then be documented separately from that particular type, e.g. "wherever you see a 'product-item' link, the URL is somewhere you can fetch a 'Product' entity".
So in a true RESTful API, there should never be a document saying "URL /products/42 will return JSON in this format", because there should be no document specifying the URL /products/42 at all. But you definitely need to document your data representations somewhere.