29 lines
1.3 KiB
Markdown
29 lines
1.3 KiB
Markdown
### 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.
|
|
|
|
### Documentation.
|
|
|
|
Documentation isn't started, yet. TODO!
|