I’m pro-client-side adapter, mostly. I believe that API “consumers” should more or less conform to the structure given by API “providers”—not the other way around.
I work with mobile partners often and I prefer to have them conform to my API spec; sometimes I’ll have multiple consumers (web app, mobile, third-party), and I don’t think any one of them should dictate what my API looks like. I see my API as a more permanent fixture of my project than the front-end framework. Tomorrow I may want to swap Ember out for React, or something else. Breaking my API periodically if this ever occurred would be counter-intuitive in my book.
I believe Ember, while opinionated, understands that it needs to be adaptable to various API styles. That is why Ember Data explicitly makes it possible to write your own adapters. This Ember ability is not hidden beneath the surface. It is well documented and encouraged.
DRF, on the other hand, is not so easily tailored. Most of the server-side solutions I’ve seen sort of monkey-patch parts of the renderer to force a certain JSON style. While many of these work well, they often feel brittle to me. I’ve mentioned working on better adaptability on the DRF server-side to @tomchristie, who is interested, but says it is not an immediate concern.
All that said, there are certain things you can do easily with DRF that are not so intrusive and make writing a client-side adapter a lot easier. My end-game consists of configuring DRF with Ember in mind, while leveraging a client-side adapter to fill in the gaps.