How Exactly Is Authorization Going To Work?

After reorganizing Mabel to reflect the decision to move my dependency declarations out of docroot/index.php and to switch to a 'one endpoint one class' approach, it was time to dig back in and go to an even greater level of detail.

Authorization seemed like a good place to start but I also wanted to flesh out the data model for user information, so I began with POST /account/create.

The business logic for this controller should be something like:

1. Confirm that the request has the authorization header and throw an exception, log it and return a 400 Computer Says No response if it doesn't.
2. Get the value of the authorization header.
3. If the value is an empty string, generate a new value and save it to persistent storage in an unauthorized state.
4. If the value is not an empty string, attempt to load it from persistent storage.
5. If the value cannot be loaded from persistent storage, generate a new value and save it to persistent storage in an unauthorized state.
6. If the value exists in persistent storage in an authorized state return a 403 Computer Says Forbidden response. You should not be attempting to create a new user account if you're already authorized.
7. If the value exists in persistent storage in an unauthorized state we're golden. Continue on.
8. Get the post data from the body of the request and translate it into something the code can work with.
9. Validate the translated data for the existence of all required fields, that those fields don't contain invalid data and that they're neither too long or too short.
10. If the translated data failed validation, return a 406 Computer Says Not Acceptable response.
11. Confirm that no other already persisted user has the same User Name, Screen Name or Email Address included in the translated data.
12. If one or more of these three fields are already in use, return a 406 Computer Says Not Acceptable response.
13. Save the translated data to persistent storage, thus creating the new user account.
14. Update the authorization header value saved in persistent storage to an authorized state.
15. Return a 200 OK response.

So yeah, that's basically what's happening behind the scenes for that particular endpoint. The other endpoints are largely variations on the same theme.