You are not logged in.

Announcement

 Téléchargez la dernière version stable de GLPI      -     Et vous, que pouvez vous faire pour le projet GLPI ? :  Contribuer
 Download last stable version of GLPI                      -     What can you do for GLPI ? :  Contribute

#1 2024-03-19 12:24:23

WG
Member
Registered: 2024-03-19
Posts: 1

Reducing the number of API calls?

Hi!

I hope someone can help us - or just crush our hopes ;)

Our data team is implementing the feed of asset data from GLPI into a data lake (using API).

The obstacle is:

Some of the asset attributes are available with a single API call for the entire asset database, which is ok.
But some of the tables we're trying to use (for example: "Infocom" for assets) seem to be available only as a "single API call per single asset". Which is doable, but would result in thousands of API calls (per day).

Official documentation apparently doesn't cover a way around it. But perhaps there is a way that's not in the documentation?


Thank you! :)

Offline

#2 2024-03-19 12:53:54

cconard96
Moderator
Registered: 2018-07-31
Posts: 2,421
Website

Re: Reducing the number of API calls?

There is no way around it... Yet.

The current API in GLPI works at a very low level and is only a thin layer over the PHP classes and the search engine.
Just like the Infocom data is in a separate tab, you need a separate API call when getting a single asset's details.

Like in GLPI when searching though, you can add columns to be able to see at least some of the infocom data. For the API, that means passing the 'forcedisplay' parameter with the search option numbers related to the columns you want to force to show.
How to determine what those search option numbers are? You have to call the /listSearchOptions/:itemtype endpoint.

Now the good news, and a little hype generation for the next main GLPI version smile.
GLPI 11.0 is the next main release and will be coming with a new REST API. It is a high-level API with more strict schema control. So, while not all data will be available (at least not to start), it will be a lot more user friendly and even come with a Swagger UI documentation.
This will exist alongside the existing API.
Now, the new REST API won't solve your issue on its own, but the new API knows how certain types of data are related like Cartridges and Printers (Cartridge > Printer Model > Printer) and even if all that data isn't shown in the REST API it enables the use of a second new feature/API.
The new REST API has a GraphQL wrapper.
This means you can define exactly what data you need from the server even across datatypes as long as the API knows how they are related.
Example:
query {
    CartridgeItem {
        id
        name
         printer_models {
            name
            product_number
        }
    }
}

While the infocom data isn't available in the new API yet, it is on my list of things to add before the GLPI 11.0 release.


GLPI Collaborator and Plugin Developer.
My non-English comments are automated translations. Sorry for any confusion that causes.
Mes commentaires non anglais sont des traductions automatiques. Désolé pour toute confusion qui cause.
Mis comentarios que no están en inglés son traducciones automáticas. Perdón por cualquier confusión que cause.

Offline

Board footer

Powered by FluxBB