Flag Parameters are Evil! (Or at least unclear)

The more parameters you have in a method call, the more chances you have to screw things up. Moreover, method signatures with boolean parameters (flags) add in clarity problems, too – even if the input parameter is well-named.

Instead of exposing a non-private method with a flag, make that method private and instead expose two well-named, explicit methods which are simple facades over the newly private method.

Instead of

protected T CreateRestServiceInstance<T>(bool impersonateEnabled)

use

protected T CreateRestServiceInstanceAsServiceUser<T>()
{
   return CreateRestServiceInstance<T>(false);
}

protected T CreateRestServiceInstanceWithImpersonation<T>()
{
   return CreateRestServiceInstance<T>(true);
}

private T CreateRestServiceInstance<T>(bool impersonateEnabled) 
{
  //wonderful shiny stuff here
}

You’re making your class’s API explicit and clear, and you’re cutting the risk of someone goofing up and missing something important – like invoking a REST endpoint as a service account instead of impersonating the user.

Not that I’ve ever done this myself, mind you…