Well, I'm not entirely sure are the details of what you're doing, so for the sake of argument, I'm going to walk you through this using a different example. Let's say, you have an invoice schema, that has several states, and your goal is to save the invoice and send an email to the client with that invoice.
Your routing would then look something like:
- GET /invoices.:format? invoices#index
- POST /invoices.:format? invoices#create
- DELETE /invoices/:invoice.:format? invoices#destroy
- PUT /invoices/:invoice.:format? invoices#update
You could also nest your routing under another resource, and maintain two sets of routes to the same controllers:
- GET /users/:user/invoices.:format? invoices#index
- POST users/:user/invoices.:format? invoices#create
Note: nested resources is a good use case of matching routes using :resource instead of :id.
On top of that, you would add in routes for your actions:
- POST /invoices/publish.:format? invoices#publish // create and publish
- PUT /invoices/:invoice/publish.:format? invoices#publish // update and publish
- POST /users/:user/invoices/publish.:format? invoices#publish // create and publish, associate with user
- PUT /users/:user/invoices/:invoice/publish.:format? invoices#publish // update and publish, associate with user
Within invoices#publish, you would want to write your api to nest the model on both the request and response, such that your other properties would relate to the request, and you would be able to update your model on the response from the nested property; in this case invoice. For data normalization purposes, it's typical to nest resources. Generally in those cases, as the reference id would be included in the model data, it's easier to just create two full sets of routes, but then to point the nested set of routes towards the non-nested route's controllers.
Within canjs, to tie everything together, you can create a publish function, that would check if the invoice has an id, and use the appropriate endpoint. You can then add on a done or then callback to your can.ajax promise to update the model with response.invoice. If applicable, you could also use the then callback to filter the response, and make your subsequent callbacks receive response.invoice instead of the full response.