# Nested URLs for Ember Data's RestAdapter proposal

**URL:** <https://discuss.emberjs.com/t/nested-urls-for-ember-datas-restadapter-proposal/5290>\
**Category:** Ember Data\
**Created:** [May 16, 2014, 9:02pm UTC](https://discuss.emberjs.com/t/nested-urls-for-ember-datas-restadapter-proposal/5290 "2014-05-16T21:02:48Z")\
**Posts on this page:** 1\
**Showing post:** 23

<div class="post-metadata">

**Author:** ![sandstrom](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/sandstrom/32/15173_2.png) [@sandstrom](https://discuss.emberjs.com/u/sandstrom)\
**Post date:** [May 18, 2014, 9:41pm UTC](https://discuss.emberjs.com/t/nested-urls-for-ember-datas-restadapter-proposal/5290/23 "2014-05-18T21:41:12Z")

</div>

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](https://stripe.com/docs/api/curl#refund_charge)).

---

_[View the full topic](https://discuss.emberjs.com/t/nested-urls-for-ember-datas-restadapter-proposal/5290)._