Great initiative! Two things that come to mind: multiple end-points for the same record and non-CRUD actions. I’d be happy to hear your thoughts!
Multiple end-points for the same record
We’ve got use-cases similar to those @bakura mentions: records exist at multiple endpoints.
Filtering encoded in endpoint path
/archived
/users/2/todos
/pending
may all return Todo
records (current user, archived; given user; and pending respectively).
This could be reorganized into /todos?filter=archived
, /todos?user=2
etc. but I think this is common (the Github API has a few).
Search results
In search, say Elastic Search, the query may contain a json payload, but any updates/writes would go to another endpoint.
Write/read and replication
There may be a read-only replica with data [geographically] closer to the user. E.g. eu.example.com/todos
may handle both read and writes, and us.example.com/todos
may be read-only.
Possible solution
Perhaps having named endpoints in the adapter would work. With the default one being inferred from the record as it is now. Such that:
-
store.find('todo')
=>/todos
-
store.find('todo', { endpoint: 'user', userId: 2 })
=>/users/2/todos
Naming is tentative, I’m not sure ‘endpoint’ is the ideal word here.
Non-CRUD actions
Don’t know if this falls under the scope of this proposal, but sometimes non-CRUD actions have dedicated endpoints. Here is an example from the Stripe API. We’ve got similar ones in ours.
Our current solution is an out-of-band request, using pushPayload
on the response, to update the model state. This works, but being able to define these actions on the adapter would be neat.
Possible Solution
// in router
record.operation('refund');
// in adapter
var ChargeAdapter = RESTAdapter.extend({
operations: {
'refund' : { path: '/charges/:id/refund', method: 'put' }
}
})
Naming is tentative, I’m not sure ‘operation’ is the ideal word here.
For example, the Strips API has a bunch of these (https://stripe.com/docs/api/curl#refund_charge).