There are a couple of use cases where it would be useful to restrict
who can use the API interfaces.

Ezio wants to restrict to developers originally so they can work on
using it perhaps to enhance the web front end. Ralf wants to limit it
to users used for automating specific workflows. This is my guess on
how to handle this.

Add two new config entries:

      xmlrpc_allowed_role
      rest_allowed_role

which are strings that name the role that must be present for the user
to use that endpoint. If the values are empty anybody can use the
corresponding endpoint. Otherwise the user must have the listed role.

Setting:

  xmlrpc_allowed_role = User
  rest_allowed_role = User
  enable_xmlrpc = yes
  enable_rest = yes

would allow any authenticated user access (assuming all non-anonymous
users have the User role). If you don't want to piggyback access on an
existing role, create a new role Rest_User and use:

  xmlrpc_allowed_role = 
  rest_allowed_role = Rest_User
  enable_xmlrpc = no
  enable_rest = yes

to disable all xmlrpc access, allow rest access only for users with
Rest_User role.

For Ezio's use case,

  xmlrpc_allowed_role = 
  rest_allowed_role = Developer
  enable_xmlrpc = no
  enable_rest = yes

should do the trick.

Ralf suggested making the default value 'User' so authenticated users
would be able to use the rest interface This would prevent users who
are not logged in from using the api's. It prevents using the API to
scrape the tracker without login.

If the web interface uses rest this would be an issue for non-logged
in users.  If it can't be coded around (e.g. rest may be used for
progressive enhancement/additional functionality only), the admin
would have to set the value to empty.

Open question, if the value is unset in the config file will the 
default
value be substituted by the current config file processing code?