Pureness

The behavior of API end points should be designed with pure functions in mind.

1. The API MUST NOT rely on a state
2. API invocations SHOULD be idempotent if their nature allows it
3. API should expect all parameters it is based on explicitly

Acceptable means of compliance

1. Stateless

Consider a customer preference to toggle a setting. The API command should not be toggleSetting but rather enable and disable respectively. Not only this transports the actual intent (the customer doesn't want to toggle; that is just a UI representation), but it's also more fail safe if the backend state for some reason diverged from the frontend representation.

2. Idempotence

Subsequent invocations of identical commands should have the same outcome. The API should not delete the third item in the list but the item with a particular ID. Subsequent attempts with the same ID won't be hazardous then.

3. Explicit input parameters

An API SHOULD NOT guess environment or context for (developer) convenience. This data should be passed along with the command, if possible.