* add domain representations
* Update docs/references/api/domain_representations.rst
Co-authored-by: Alexander Ljungberg <aljungberg@wireload.net>
* Update docs/references/api/domain_representations.rst
Co-authored-by: Alexander Ljungberg <aljungberg@wireload.net>
* Update docs/references/api/domain_representations.rst
Co-authored-by: Alexander Ljungberg <aljungberg@wireload.net>
* Update docs/references/api/domain_representations.rst
Co-authored-by: Alexander Ljungberg <aljungberg@wireload.net>
* Update docs/references/api/domain_representations.rst
Co-authored-by: Alexander Ljungberg <aljungberg@wireload.net>
* Update docs/references/api/domain_representations.rst
Co-authored-by: Alexander Ljungberg <aljungberg@wireload.net>
* add custom domain subheading and TOC
this way it can be seen at the beggining there are advantages over views
and computed fields.
* important note for scache reloading
* clarify advantages
* why not create a type?
---------
Co-authored-by: Alexander Ljungberg <aljungberg@wireload.net>
* Clarify vnd.pgrst.object+json is also Content-Type
The previous docs explained how the `Accept` header could be set to
`application/vnd.pgrst.object+json`. This change indicates the resulting
response `Content-Type` begins likewise.
While robust clients will correctly identify that
`application/vnd.pgrst.object+json` data are json, many others which
naively check the `Content-Type` is `application/json` will fail to
recognize what should be a valid `Content-Type`.
steve-chavez