This section describes the primary methods for processing incoming requests: using functions from the Open Integration Package (OpenIntegrations) standard library and custom extension functions.
As previously mentioned in the documentation, each handler is characterized by a function responsible for generating responses to incoming requests. By default, Melezh includes the complete set of methods from the Open Integration Package libraries - these methods can be selected as processing functions when configuring individual handlers.
In addition to the standard set of functions from the OpenIntegrations, Melezh can use methods from custom `.os` scripts as handler functions. For their correct interpretation, three conditions must be met:
+ The method must be a function that returns binary data, a string, or a JSON-serializable collection (array, structure, or mapping without non-serializable fields)
+ The script file must have a correct name (no spaces, preferably using Latin characters), `.os` extension, and be placed in the `extensions/Modules` subdirectory of the main Melezh directory
This is the standard EDT comment format but with three distinctive features: the second line is a brief function description (optional), parameters have a fourth description block - CLI style argument name, the parameter description cannot use the `-` character except as block separators
In the standard distribution, the `extensions/Modules` directory contains a `RequestsEcho.os` module that can be used as an example when creating new extensions:
It is also important to note that when using extension functions, especially for handlers with the GET or POST + `form-data` types, values may arrive in unsuitable data types. Melezh does not automatically convert data into the required types, except for those that can be explicitly determined during JSON reading or parsing of `multipart/form-data` (binary or string).
To convert values to the appropriate types, you can use custom converters or those already used in the core functions of the Open Integration Package. They can be found in the module [OPI_TypeConversion](https://github.com/Bayselonarrend/OpenIntegrations/blob/main/src/en/OInt/tools/Modules/OPI_TypeConversion.os)
It is recommended to keep backup copies of extension modules in another location, as in certain cases, updates or removal of Melezh, as well as image rebuilding (if Docker is used), may result in the deletion of these files! You can also specify any third-party directory for storing extensions using the `ext_path` setting (recommended)
In some cases, simply obtaining processed data and returning a response body is not sufficient. For low-level interaction — such as modifying the response status code and headers, as well as directly accessing request data — extensions can utilize the reserved option `melezhcontext`.
To use this option, specify `melezhcontext` as the CLI name for any of the function's parameters within the documentation comment:
```bsl title="Static.os (Melezh extension)"
// Get file from folder
//
// Parameters:
// Directory - String - Folder path - catalog
// FileName - String - File name with extension - file
Return New Structure("result,error", False, "Not Found");
Else
Context.Response.ContentType = MIME;
Return New BinaryData(FullPath);
EndIf;
EndFunction
```
This option is not displayed in the list of arguments within the web interface and always contains a value of type `HTTPContext` (a native web server type in OneScript used for handling HTTP requests and responses). For more information on working with context, see the [OneScript repository](https://github.com/EvilBeaver/OneScript/tree/develop/src/OneScript.Web.Server).
:::important
When implementing custom extensions — particularly those involving `melezhcontext` — it is strongly recommended to use the OneScript version of Melezh during development. This enables running the project in debug mode (e.g., in VSCode) and setting breakpoints to inspect runtime values and context data.