Keep your REST server performing at its best

With 4D 21 R4, you gain even more control over your REST server resources thanks to a new quota management mechanism. As your applications grow, your data can be consumed by a wide variety of clients: web applications, mobile apps, third-party services, custom integrations, and now even AI-powered tools through MCP servers.

Each client interacts with your REST APIs in its own way, generating requests with different levels of complexity and frequency. To ensure optimal performance in every situation, it is important to maintain control over how server resources are used.

HDI_REST_Server_quotas

Quotas, why?

On the 4D REST server, requested data can be stored in memory as entity sets to improve efficiency and navigation.

In well-designed applications, these entity sets are released when they are no longer needed. However, in large and diverse ecosystems, it is not always possible to predict how clients will behave or whether every allocated resource will be properly released.

Without quotas, inefficient management of entity sets in a single session can affect the performance experienced by other users.

That’s why 4D 21 R4 introduces session quotas for entity sets. With just a few lines of code, you can define resource limits that help keep memory usage under control, protect your server from excessive consumption, and ensure consistent availability for all users.

The result is a more resilient REST server, easier administration, and greater confidence when exposing your data to an ever-growing number of consumers.

set up quotas for the current rest session

The Session command returns an object representing the REST session. This object includes a quotas object property (an instance of the 4D.QuotaManager class). 

Example

Here is the Session.quotas object. 

{
        "nbEntitySets": 100,
        "maxEntitySetTimeout": 420,
        "defaultEntitySetTimeout": 300,
        "currentValues": {}
}

It exposes the following properties, which can be used to configure quotas for the current session:

– nbEntitySets: the maximum allowed number of entity sets allowed in memory

–> Too many entity sets can consume excessive memory and impact REST server performance. This property allows you to limit the number of entity sets that can be stored concurrently in memory for the current session.

– defaultEntitySetTimeout: the default inactivity timeout allowed for entity sets.

–> Adjusting this property helps prevent excessive memory usage because entity sets are automatically released when they remain unused for longer than the specified period.

– maxEntitySetTimeout: the maximum inactivity timeout for entity sets

–> adjusting this property prevents the creation of entity sets with excessively long inactivity timeouts.

Additionally, the currentValues property also provides an nbEntitySets attribute that indicates the number of entity sets currently held in memory for the session.

Note: An Undefined value means that no quota is applied and the REST server uses its default behavior.

Limit the entity sets number

To do this, update the nbEntitySets property.

Session.quotas.nbEntitySets:=100

In the example below, the session is limited to a maximum of 100 entity sets in memory, and 100 entity sets have already been created:

{
  "nbEntitySets": 100,
  "currentValues": {
    "nbEntitySets": 100
  }
}

Upon the next attempt to create an entity set, an error is returned as long as 100 entity sets remain in memory:

{
    "__ERROR": [
        {
            "message": "Max number of entitysets has been reached for this session.",
            "componentSignature": "dbmg",
            "errCode": 2017
        }
    ]
}

a more concrete example

The forceLogin mode provides an initial layer of protection by preventing entity sets from being created in unauthenticated sessions. However, even after authentication, you may want to further restrict the number of entity sets that can be created by specific user roles.

In the example below, the forceLogin mode is enabled.

A user with the Guest role is limited to a maximum of 100 entity sets.

exposed Function authentify($credentials : Object) : Boolean
	
	var $result:=False
	
	Session.clearPrivileges()
	
	If ($credentials.identifier="Guest")
		Session.setPrivileges("")
		Session.quotas.nbEntitySets:=100
		$result:=True
	Else 
		// Authenticate other users
		// ... 
                Session.quotas.nbEntitySets:=200
                $result:=True
	End if 
	
	return $result

Of course, if you don’t use the forceLogin mode, quotas can also be applied in the same way using the Session command..

set up the default entity inactivity timeout for entity sets

By default, the inactivity timeout for entity sets is two hours. You can change it by updating the defaultEntitySetTimeout property (in seconds).

Session.quotas.defaultEntitySetTimeout:=300  // 5 minutes

Entity sets created by a request such as:

/rest/People?$filter='ID>=1'&$method=entityset

will be automatically released after five minutes if they are not used during that period (that is, when no inactivity timeout is explicitly specified in the request).

Set up the maximum inactivity timeout for entity sets

You can define the maximum inactivity timeout allowed for entity sets by updating the maxEntitySetTimeout property (in seconds).

Session.quotas.maxEntitySetTimeout:=420  // 7 minutes

If an entity set is created with an inactivity timeout that exceeds this limit, it will automatically be capped at 420 seconds.

For example, for the following request:

/rest/People?$filter=ID>=4&$method=entityset&$timeout=600

the entity set will be released after 420 seconds, as the requested 600-second timeout is ignored.

Try the attached HDI and enhance the robustness of your applications immediately!