Member Routes

[owensims1]

Please leave open until at least Wednesday, June 14th.

[gmkohler]

Any blog posts about this?

[owensims1]

@gmkohler I'll dig around. I agree that it'd be nice to have a Resources (no pun intended) section for each guideline.

[ghost]

Is this because ember-data makes assumptions about being RESTful?

In some cases it's useful to have a separate domain model for a catering-order-cancellation because:

1. this guarantees that the catering-order doesn't need to be mutated accidentally,
2. you can create a cancellation without necessarily loading the catering-order in the store.

There are good patterns for action style routes in Ember, notably with ember-api-actions.

[ghost]

This seems to be entirely a conversation about using RESTful routes vs action style routes since both patterns allow definition of sensible domain models and that Ember works well with both styles.

I feel neutral about RESTful vs action routing because in some cases a RESTful route is more useful and in some cases an action route describes the situation better. It'd be a shame to prevent ourselves from using the best tool for the job.

[mmun]

If POST /catering_orders/1/cancel returns a catering order resource (e.g. the same shape of thing you'd get from GET /catering_orders/1, except maybe the cancelled attribute is now true) then I have no problems with member actions.

If it returns a a separate kind of resource then I think it often should be refactored the way you've suggested, e.g. if POST /catering_orders/1/cancellation returns an cancellation object with a shape like { cancelled_order_id: 1, replacement_order_id: 2 }.

Prevents existing controllers from becoming too busy

Neither case should result in busy controllers. In both cases you should extract the bulk of the work out to interactors (or whatever your favorite word for the command pattern is).

Eases the use of ember-data

As @binhums mentioned, ember-api-actions makes this pattern nice to use in Ember Data.

[owensims1]

I'm thinking more in terms of keeping that paths through an API straightforward and clean. For example, if you're going to end up with a domain model, MealCancellation, that actually cancels the meal and does related necessary actions, I believe it's more intuitive that API actions that use that would come from MealCancellationsController than it would MealsController#cancel. Cancelling a meal only is partly related to a Meal object itself.

Sure, member actions can be fine when the action is very simple such as the toggling of a field in the database on the related record (meal.cancelled = true), but I'm arguing that they rarely stay that simple.

===
Slightly separately, here's thoughtbot's language rubric for their guides:

"Avoid" means don't do it unless you have good reason.
"Don't" means there's never a good reason.
"Prefer" indicates a better option and its alternative to watch out for.
"Use" is a positive instruction.

Perhaps "prefer named resources over member or collection routes` is what we want, but I do think this is important.

[ghost]

I believe it's more intuitive that API actions that use that would come from MealCancellationsController

Looks like an argument to favour pairing web api to the domain model which I'm down with.

Perhaps "prefer named resources over member or collection routes` is what we want

Avoid and prefer seem more or less equivalent in this case given that I don't expect people to do this without good reason.

I'd be down for merging if we remove the argument for Ember data being easier.

[mmun]

Here's a relevant article: http://jeromedalbert.com/how-dhh-organizes-his-rails-controllers/.

I like that Inboxes::PendingsController is namespaced (e.g. not PendingsController) to 1) avoid cluttering the root folder and 2) have closely related files show up closely in your file explorer.