API adoption principles:

We build interactive systems and Application Protocol Interfaces are the languages among our component objects including human commands and responses.

The EIES principle of orthogonal objects and operations capitalized on common language of all objects (rarely of a category) conseptually, rather than something constrained to be useful only for a particular type object.
And the EIES user programming model facilitates automation of user tasks and development of the user agent. .While common language is the goal participants often already have their own language so we must gateway the languages, ideally just once, not a gazillion times for each use case. The user command, "modify X" gets gatewayed to an HTTP PUT to the X resource URL in our RESTful API. It is sufficient that the languages are transmutable to one another.

For security the defactio primative standard is GssApi and should be our base language of choice, where it applies, REST where it applies, OAuth, OpenConnect, SAML, XACML, SCIM, etc., and borrow APIs from the tools we use, perhaps ForgeRock so that we can speak the same language, or gateway simply, to object resources that encapsulate their behavior in one place, rather than every place, very DRY.
REST is easy in the sense that all it really requires is URI's, and a basic object design, even if your singular object is "service", a taboo, but not excluded.

REST wants to be a formal language you extend with your objects responsibly or not. Done responsibly, your extensions are self documenting and minimal such that they are readily usable by the developer. It is a natural language where each developer develops their own dialect toward their interpretation of the standard.

http://www.restapitutorial.com/lessons/restfulresourcenaming.html is a good start but they is a lot to be learned in order to define an api responsibly.

SecureObjects translate language accross APIs for the services they offer in meeting their responsibilities.