Request Lifecycle

This diagram represents a high level overview of the standard request made in the application. This pattern has been used through the entire application and should be consulted whenever developing new or existing features.

Certain requests will omit the use of transactions where no modification to data will be made. For example, when listing organisations.

Authentication

This part of the lifecycle check if the route requested requires an authenticated user to invoke it. If the user is not authenticated, then the response will be flat out rejected and not progressed.

This is achieved by the use of the auth:api middleware which applied to controller methods within the controller's __constructor().

Request Validation

Every route (controller method) has a corresponding request class which contains all the logic for:

1. If the authenticated user is authorised to make the request (usually if their role is high enough in the hierarchy).

2. If the parameters (if any) pass the validation rules provided.

The request class is passed to the controller method's constructor and invoked automatically by Laravel. So no logic needs to be contained within the controller itself.

Transactions

For any logic that modifies the database in any way, a database transaction is wrapped around the entire contents of the controller method. This results in the transactions being rolled back in the event that an exception is thrown.