How would design a wrapper for a large, multi-response api like the one described below?

Let me explain. Lets say there exist some service at some organization that exposes information on a company's assets, from employees company-issued devices(laptops and issues) to the the large xerox printers on each floor to the large servers in the many different server rooms. Each of these objects (laptops, enterprise printers, servers) have their own set of attributes.

ex. /api/v1/assets

This service is standing in front of many different asset management databases. You basically send this large JSON object to ask for you want whether it be information on users personal laptops or information on servers.

Request may look something like this

{ "asset_type" : "laptop", "attributes" : ["assignee", "os", "physical_address", "manufacturer"]}

Response will look something like this

[{"assignee" : "238947", "os":"Win7Prem", "physical_address" : "3C:BF:12:90:0A:X2", "manufacturer":"Dell"}

And just imagine that each of these object had 20-30+ attributes and with each request you could pass a filterList that allows you filter the response based on the values of 1 or more attributes. For example, pulling all laptops where Manufacturer="Dell".

How would you design an api wrapper for this to be used in another application?

Would you just keep these pre-built queries in a file on the server and grab it when you need it? Maybe a seperate server for queries and then just make the api calls?

OR...

Would you write an AssetsAPI class and create methods? How would you organize your calls ? Keep track of queries and attributes? Would you create classes for each of the asset types?

Let me mention that the asset data is being called from app, going thru some enrichment process, and then served from calling api as another api response