Network requests

Another useful section of the Developer Tools is Network. In it, you can track all network requests and detailed information about them and parse the received answers. Let's look at the example of a table with information about countries. It was created in module 8, and we know for sure that a GET request must be made to populate this table. Let's open the corresponding page and ensure that the request is actually sent and correctly composed.

The table was made correctly, it is automatically filled in, and therefore the very fact of sending the request was not in doubt. It can indeed be seen in the Network section. But its potential absence could just give an answer to why there is no data in the table. In this case, it would become clear that you need to look for the reason for the absence of a GET request (possible options: the correct trigger for sending is not set; the event that activates the trigger does not occur; the business process was compiled with errors).

For greater convenience in displaying the necessary information, you can immediately activate the Fetch / XHR filter (various service requests that are not needed at this stage will not be displayed) or even use keyword search.

Headers

Here you can parse the request in all details and make sure that it is made correctly. In this example, on the Headers tab (General -> Request URL), the request is entirely displayed, with the parameters used.

We can verify that the parameters are set:

• _offset=0 -the data is requested as is, from the very beginning and without indentation
• _with=1 - in addition to information about countries, information from related tables is also requested (in this case, 1 means getting information about cities)
• _limit=10 - the request is limited to the first 10 elements
• _sort_order=ASC - data sorted in ascending order
• _sort_by=name - data sorted by name

The same parameters can be seen on the Payload tab. It is relevant when it is necessary to study the composition of the request in detail. This is often required when sending POST requests when a model object is passed for writing to the database, and you need to consider its structure in detail.

Preview

But the greatest interest is often not the request itself but the answer to it, the result of the request. You can see it in a structured form on the Preview tab.

In this example, you can see that information about three countries was received in response. You can also see their name, description, data about the related cities, and various service information (ID, creation time, modification time, etc.). The absence of any data here will explain why this data is not in the table either (which means you need to understand the business process as a result of which this data is supposed to be obtained). Or vice versa, the presence of additional data will make it clear that the table can be made more detailed.