informatiqal / qlik-rest-api Goto Github PK

I think the XrfKey should come between the request and the filter. There doesn't seem to be a way to pass that to the Get method and have a valid output
If I pass
/qrs/app/hublist?filter=Name%20eq%20%27MyappName%27
The xrf is appended, but Qlik seems to fail to recognise the filter.

It seems that paging is not returning the whole data for SaaS API.

The observation is that at the moment when there is more than one page of data the MakeRequest method will return only the last page data instead of all pages data

When using FormData method there should be a way to specify the content type (if the value is file).
At the moment the content type is hardcoded to application/x-zip-compressed which prevents uploading other file types (image, ico etc) using this method

Drop mocha and chai in favour of vitest

Because of qlik-saas-api -> App id vs resourceId there is a need to be able to pass additional options when defining the config.

These options are fully optional and a bit specific but its good to have such capability

At the moment the returned data is from QMC point of view.

There should be a dedicated config value (for Repo API only!) that sets the security headers (https://help.qlik.com/en-US/sense-developer/November2022/Subsystems/ProxyServiceAPI/Content/Sense_ProxyServiceAPI/ProxyServiceAPI-Injected-Req-Headers-X-Qlik-Security.htm)

At the moment the package expects some authentication data to be provided (header, jwt, certificates etc). But if the package is used in browser environment and the app, that is using the package, is already authenticated somehow (eg session cookie is already available in the browser) then there is no need extra authentication to be provided to qlik-rest-api.
For this reason authentication property should be made optional (or to have a dedicated authentication property for none)

For QlikGenericRestClient it will be nice to be possible to define base path parameter. The value of the parameter will be append to the end of the base url path.

It just to avoid copy-paste the same value over and over again.

Axios have onUploadProgress and onDownloadProgress options available. It will be nice if these can be utilised and to emit (?) the progress

Upload temporary content for Qlik SaaS returns the location of the uploaded content in the location header. In this case the request have to return the location instead of following it or returning the response data (if any)

Two more parameters to be added (in Post for now) - followLocation?: boolean and returnLocation?: boolean. These params makes sense only if there is a location header in the response

• followLocatrion (default true) - if false will not redirect the request and will return the data or the location header based on returnLocation
• returnLocation (default false) - (if followLocation == false) returnLocation == true returns the content of the location header. If false returns the response

First of all, thank you for your work. Its really a nice library to interact with Qlik.

I am trying to use the Generic client to access Qlik Product info using https://help.qlik.com/en-US/sense-developer/November2022/Subsystems/AboutServiceAPI/Content/Sense_AboutServiceAPI/AboutServiceAPI-Introduction.htm
But it does not work.
I am authenticating using the certificates. This works for QRS api but not for about service api.
Can you share any insight?

Probably useful only for SaaS APIs

Expose method that helps with generating FormData

Since browsers expose this already, this method will be useful when using the package in Node

When uploadint to temp content api additional headers have to be passed
For example:

There should be an option to pass additional headers when making the request.

Not all data is returned if more than one page of data is available

Hi Stefan,

I'm unsure if this is an issue itself or its just a matter of documentation. When authenticating I need to pass over additional attributes that will be used in Security Rules + Section Access.

Using enigma I think you pass something like this:
Attributes: [{ Group: '1234' }, { Group: '5678' }, { CLIENT: 'COCA COLA' }]

Is this available today? I've tried a few different variations and can't seem to get it to work. It might just be how I am doing it though.

Thanks again,
Andy

When calling Patch method the underlying function is actually executing Post method

Qlik SaaS Rest API returns more info when the request is failing.

For example: making request to create new data-alert returns error with status 500 when the app, specified in the body, do not exists. In the current stat of the library the response will contain only the status code, status code text and the message.

When checking the raw response though, we can see additional information that is describing the error(s) in more details:

This extra information have to be returned (if exists) as an addition to the existing fields

At the moment there is only one api version /api/v1/ but in the future Qlik might add more. For this reason api version should be possible to be specified. If not specified then it will defaults to 1

At the moment only the status code/message is thrown. SaaS returns more errors information in the response. This info should be thrown as well

Small checks on the config - if host is passed, if authentication section exists etc

Some logic (like processing pagination) is only applied if the request is made against Qlik SaaS environment. There is no need to run these portions of the code when non-SaaS environment (aka QSEoW) is targeted.

Is it possible to separate the code based on the environment?

Is it possible to replace Axios with Fetch?

Fetch is available in the browser and in Node? Probably will have to wait until Fetch is in Node's LTS version (18+)

The main benefit will be that then the qlik-rest-api will be dependency free

For some reason FormData module is not exported in the final bundle

At the moment the return type of all methods is IHttpReturn. It is defined as:

interface IHttpReturn {
  status: number;
  statusText: string;
  message?: string;
  data: AxiosResponse["data"];
}

With such declaration the data property will be of type any:

Although this is not an issue itself it's not a good practice to return any.

Another inconvenience is that when using the method

• the data have to be cast to the expected type
  
• or even left without a type. And this will be a valid syntax since the return type is any

And because of these the code, that uses the method, can potentially throw an runtime error, which could have been avoided if the method was requiring type

The solution is to allow the methods return type to accept generics. If return type is not provided when calling the method then its data property will be of type unknown and any attempt to use some of the data's properties will result an error in the editor:

But if return type is provided then the return data properties are "known" and can be used:

The provided return type will be applied only to the data property of the IHttpReturn interface. The rest of the properties will behave the same (even without specified return type):

The new IHttpReturn definition will be something like:

Some reponses are directly returning null (possible issue on Qlik's side).

The request function should not fail in such cases and shold return an empty object (at least)

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• Update dependency @rollup/plugin-typescript to v11.1.6
• Update dependency axios to v1.6.8
• Update dependency ts-node to v10.9.2
• Update dependency typedoc to v0.25.13
• Update dependency @types/node to v20.12.7
• Update dependency dotenv to v16.4.5
• Update dependency rollup to v4.14.3
• Update dependency typescript to v5.4.5
• Update dependency vitest to v1
• Click on this checkbox to rebase all open PRs at once

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

All clients are extending the BaseClient class and they are implementing its methods.
The code will be much simpler if the BaseClient is an abstract class.
After this there will be no need for the clients to implement the methods themselves. Thety will have to just pass the config object in the contructor

At the moment Post and Put methods accept Buffer as data parameter. In order to handle upload of large files these methods should not rely on Buffer but rather passing stream to Axios. Axios will then handle the upload

Qlik released OAuth authentication workflow. In general the authentication workflow will provide access_token that can be passed to the request to authenticate.

Have to allow the config to accept client_id and client_secret. If/when these two properties are passed then the logic should send request to oauth/token to receive the token details (the token itself and the expiration date).

The instance will hold the token and its expiration data and will try to re-use the token if not expired. If the token is expired then the instance will obtain a new one.

Blog post
Rest API examples