It’s possible I’m being too precious about this, but it feels wrong to be including an
id value in requests if the server is going to ignore it. There is an established pattern for interacting with resources in the case when there is only a single resource that a client can legitimately access, and I’d like to see the REST adapter implement it.
I’d hesitate to say that the Ember Way, or even the Ember Data REST Adapter Way, is wrong, but as far as I can tell, this case isn’t handled, and your reply seems to confirm this.
In the particular case of user profiles, there is a practical disadvantage to using URLs with
id values in them. A naive or incompetent programmer working on the server end might just plug in something like
inherited-resources with the defaults and end up using the
id to retrieve the record, thus allowing a malicious user to edit other people’s profiles. (I seem to remember that Diaspora did something like this when it was first released.)
User profiles aren’t the only case to consider, though. For instance, another classic example is when a project has a single manager, so you want URLs like
/project/1/manager/99. Of course, I’m talking here about the URLs provided by the API, which Ember Data talks to, not the URLs in the Ember application that the end user sees.
I don’t know enough about the internals of Ember Data to feel competent to make a specific proposal. Does it make sense to have a
singletonModel class? Or is the idea of a singular resource specifically a REST thing, which should be dealt with (in some unspecified way) by the adapter?