gistfile1.txt

// Handle specific permissions
app.service(resourcePath)
  .before({
    update: handleUpdatePermissions
  });

/**
 * Handle permissions when updating a project
 *
 * @param hook {Object}   -
 * @param next {Function} -
 */
function handleUpdatePermissions (hook, next) {
  var user = hook.params.user;
  var projectId = hook.id;

  return next(new Error('Just for test'));
  /* propagate and crash the server with an error 500 response
  for the client. How to handle that knowing I don't have access
  to the generated rest route for the update (PUT) */ 
  
}

That should work. Did you configure your own error handler? Are you using a view engine? It might be blowing up because you are using a view engine and I'm making a shitty assumption here. If you are using a template engine then it assumes that you have a /500 and a /404 route.

Hmm, I didn't register any error handler no and I don't use a view engine for this part, I use it as an internal API so I (should) receive a json response =/

I will register one temporary but the default behaviour would have been enough ^^

'application/json': function(){
      res.json({
        'code': err.code,
        'name': err.name,
        'message': err.message,
        'errors': err.errors || {}
      });
    },

hmm weird. And it's crashing hey? I'll see if I can reproduce this evening and get back to you. The next few weeks we are doing a bunch of changes to make things much more solid for an official 1.0-1.1 release.

Awesome :) A take advantage of this chat for asking a last question. Is it plan to handle advanced rest routes please?

Let's consider a simple example with a resource "group" containing an id, a name and a collection of users.

Will we be able to add the user with id 2 to the group with id 123 with:
POST /api/groups/123/users/2

And to remove this same user from the same group with:
DELETE /api/groups/123/users/2

I currently work on having these features if it's not available at the moment (I may be wrong..). I'll push a PR if you guys are interested :)

Well, we sort of support this with feathers-associations but after starting down that road we realized that you don't even actually need routes like that. You could just call /api/users/2. No need to complicate it by adding more params to your route.

Think about it, when you are calling /api/groups/123/users/2 you already have the user ID. This has come up quite a few times so we are going to be addressing it much more clearly in the documentation in the next release.