1.4 KiB
Consistency in error management
Both exceptions and error reponses are used. A choice should be made between the two options. A combinaison of both is fine as long as the logic is comprehensively documented.
Response::Error class is overused. A simple error message is given instead of specific messages for each recurring error. In the same time, some exceptions (such as AdminAuthenticationException) are used a few times for the same kind of errors.
Authorization rules should be clear and documented. Currently, some operations are restricted to an admin, defined explicitely by the user admin boolean. These operations could be delegated to simple users with some specific fine-grained authorizations.
Requests work mostly on current user, but some take a UserID to identify another user. Requests should either always work on current user (which implies to create new requests working on another user) or always take an optional UserID parameter.
Some requests require to be authenticated without either accessing confidential data or modifying any entry in the database. Check for inconsistencies.
Structures, not classes
Maybe in some cases, it could be great to use structures instead of classes. They are simpler, use less memory and computation.
CLI client
Current client authc lacks most requests.
Documentation
Documentation isn't started, yet. TODO!