Request Lifecycle

Quick Reference

The request arrives at `index.php`
Framework initialisation is performed
The router determines the object and action
Schemas are loaded
Data validation and normalisation are performed
Access permissions are checked
The action is executed
A JSON response is generated

Entry Point

The root file `index.php` serves as the entry point for all application requests.

All requests are routed to `index.php` using Apache or Nginx server configuration.

The `index.php` file contains very little code. Its primary purpose is to start the framework core initialisation via `framework/bootstrap/init.php`.

Framework Initialisation

The framework/bootstrap/init.php file is responsible for loading the framework core.

1. Core Loading

First, the loader includes the file framework/bootstrap/loaders/core.php, where the base `API` class is defined. It contains the framework's core functionality upon which all subsequent processes are built.

2. Configuration Loading

Next, the loader includes the system and application configuration files through framework/bootstrap/loaders/config.php. Configuration file locations: framework/config/ and app/config/.

3. Library Loading

At this stage, Composer libraries are loaded via framework/bootstrap/loaders/libs.php, and the main initialisation processes are performed (database connection, Sphinx search engine, and so on).

4. Language File Loading

The file framework/bootstrap/loaders/lang.php is loaded, which selects and loads one of the languages available in the system.

5. Module Loading

The file framework/bootstrap/loaders/modules.php loads the system and application modules connected to the project.

Routing

Once the core has been loaded, the request is passed to the router at framework/bootstrap/loaders/routing.php. This is where the request processing pipeline is started and the request is redirected to the specified `action` script containing the request's business logic.

Request Structure

The router first validates the request structure.

The framework uses a command-oriented API conceptually similar to JSON-RPC. All requests are sent through a single HTTP endpoint in JSON format.

Property	Type	Description
object *	string	The object targeted by the request
action *	string	The action being called
data	object	Request body

Request example:


{
    "object": "drivers",
    "action": "get",
    "data": {
        "is_active": true,
        "company_id": 12
    }
}

Response Structure

Responses are also returned in `JSON` format. A response consists of a status, a payload, and additional details.

Property	Type	Description
status *	integer	Response status code
data *	mixed	Response payload
detail	object	Additional information

Successful response example:


{
    "status": 200,
    "data": [
        {
            "id": 7,
            "first_name": "Michael",
            "last_name": "Sanchez",
            ..
        },
        {
            "id": 8,
            "first_name": "Milana",
            "last_name": "Bailey",
            ..
        }
    ],
    "detail": {
        "rows_count": 43,
        "pages": 3
    }
}

Error response example:


{
    "status": 403,
    "data": "Permission denied",
    "detail": {}
}

Loading Action and Object JSON Schemas

Schemas define the core request-processing logic and required permissions.

Schemas are what allow the framework to understand the purpose of actions and the overall structure of the application.

Application schemas are loaded from:

app/schemas/actions/{object}/{action}.json

Framework default schemas are loaded from:

framework/default_schemas/actions/{object}/{action}.json

Object schemas are loaded in the same way, using the following paths:

app/schemas/objects/{object}.json framework/default_schemas/objects/{object}.json

Request Pre-processing

Performs required parameter checks, type casting, value normalisation, file field processing, and data validation according to the object schema.

The result of this stage is a validated and prepared data set ready to be passed to the action handler.

Access Control Check

After successful request validation, the system checks the current user's permissions according to the action schema and object settings.

If the required permissions are not available, request execution is terminated and an access error is returned.

Business Logic Execution

System action scripts are located in:

framework/actions/system/{object}/{action}/

If a suitable `action` is not found in `app`, the framework searches among the system actions.

Application action scripts are located in:

app/actions/{object}/{action}/

Before, Custom, After

Each action may consist of multiple execution stages. The framework sequentially runs pre-processors, the main business logic, and post-processors, forming a unified action execution pipeline.


actions/
    remove/
        after.php
    get/
        before.php
        after.php
    sendEmail/
        custom.php

Execution order:

before.php
custom.php or core action
after.php

before.php

Action pre-processor. Executed before the main action and allows modification of input data, addition of conditions or filters, and execution of preparatory business logic.

custom.php

Main action handler. Contains custom business logic and can be used both to implement new actions and to completely replace the framework's default logic.

after.php

Action post-processor. Executed after the main action and allows modification of the result, addition of extra data, or post-processing of the response.

Schema loading example:

Request: users → get

The following will be loaded:

# Action schema
app/schemas/actions/users/get.json

# Object schema
app/schemas/objects/users.json

# Business logic
app/actions/users/get/before.php (optional)
app/actions/users/get/custom.php (or framework/actions/core/get.php)
app/actions/users/get/after.php (optional)