Skip to main content

Suggest an Idea

Vote for your favorite Qlik product ideas and add your own suggestions.

Announcements
Welcome to Qlik Community! Check out our new navigation! FIND OUT MORE

Accept "X-HTTP-Method-Override" in QRS API

blaise
Partner - Specialist
Partner - Specialist

Accept "X-HTTP-Method-Override" in QRS API

As Qlik Rest Connector cannot use PUT (any verb except GET/POST) we really need QRS API (and also other QS REST API's) to accept the X-HTTP-Method-Override workaround.

Tags (2)
6 Comments
Lech_Miszkiewicz

"X-HTTP-Method-Override" should be allowed in Qlik Sense APIs or below idea implemented ASAP: https://community.qlik.com/t5/Ideas/Support-full-range-of-HTTP-methods-PUT-DELETE-UPDATE-etc-in-REST...

 

i understand we can use other tools to talk to  API, but the problem is in the fact that it is not out of the box anymore and it is another component which needs special attention and clients dont want that. It will be difficult also to intergrate such solution with Qlik scripts which in typical scenarios can for example:

  • check current app id and name
  • check or set some variables during reload
  • use those to setup for example app description which would display current version of the app.

So in short - very simple task which could be completely done by running qlik script in hub or QMC which is exactly what clients want.... they want one vendor who provides solutions end to end - hence this is so important!

Meghann_MacDonald

Hi @blaise 

In the future, please only use 1 label per post. 

Meghann

Jeffrey_Goldberg
Employee
Employee

Hi there, please help me understand the use case of the REST Connector and PUT.

 

Qlik Script is for loading data into apps. I understand the REST Connector provides a mechanism for doing a lot more of the things with Qlik, but that doesn't make it the correct hammer for the nail you're trying to pound.

 

jg

Status changed to: Open - Not Planned
blaise
Partner - Specialist
Partner - Specialist

Hi @Jeffrey_Goldberg and thanks for taking the time to discuss this!

I do understand the hammer for the nail anology and Qlik Rest Connector will most likely never be the correct hammer, but for most of the Qlik community (mostly qlik developers) it will get the job done. Thinks like extracting custom properties and users and if needed update those is a task well suited for a Qlik developer - in smaller firms there might not even be a "real" developer that could solve it with PS/JS/PY.

 

Lech_Miszkiewicz

Hi @Jeffrey_Goldberg 

I agree with you & @blaise  with the "hammer to the nail analogy" however as a partner I worked with hundreds of clients who had no developer nor technical in house support. I was like you but my point of view changed with the time. The more you work with Qlik audience the more you understand they thinking. 

Qlik audience are 99% of the time people from business. They are not technical, they don't have access to servers and max what they do to maintain Qlik Sense is access QMC or update configuration XLS files.

Having ability to automate proceses for them using tool they understand (QMC) we could have a lot more flexibility in setting up smart environments. They are not going to desing their own scripts in 3rd party tool, they are not interested in "another" component they will not understand. 

I think the whole understanding "why do we need this?" is because I work on daily basis with business users (despite being technical) and I hear users every day. I ask them the same question you asked us here and I listen what they have to say. Then I see their point and I pass it over here. I would not bother looking if it wasn't frequent request or if I would not see benefit of having such solution implemented.

 

You are so wrong with this sentece "Qlik Script is for loading data into apps@Jeffrey_Goldberg

If you only knew how many people are now using all around the world Qlik scripts which I have written to run NPrinting API from Qlik Sense or QlikView (https://nprintingadventures.com/2019/04/08/nprinting-api-qlik-rest-subroutines). Those scripts don't load data to Qlik Sense apps - they are just used to run API, which is exactly what people would like to do with Qlik Sense API's as well and which is exactly why this idea was created and I searched for it and voted for it. I think this analogy should be more than sufficient for you to understand the need of additional methods in Rest connector, given that NPrinting API supports "X-HTTP-Method-Override" there we are using also PUT and DELETE methods to run APIs.

I understand we may again have argument and you will say that this is not a right tool for the job and I would say to show me what is right tool and if Qlik is willing to support such tool officialy so clients can have single solution provider...

...and let me ask you this question:

Why is Qlik so unwilling to add support for additional rest connector methods or allow for "X-HTTP-Method-Override"?

 

thanks

Lech

simonaubert
Partner - Specialist II
Partner - Specialist II

Hello all, and especially @Jeffrey_Goldberg 

I don't know for you but having dozens of tools and languages needed for what I have to do is not the best world. I understand the hammer is the best for nail and that screwdriver is better for screws. However, you can also imagine having a screwdriver at the other hand of the hammer and it still work fine. Maybe a mashup in JS+html would work better for API. I don't know. But what I also don't know is Javascript and HTML while I have 7 years experience on Qlik scripting. On the other hand, I'm also consultant on Alteryx which provides sooo many tools that I would say you can do almost everything that includes a data issue with that, and still with ease.

API Capabilities such as overwriting the method, having the put and delete...  would change a lot of things for me, especially the delivery of application or the delta reset or.. ooooh so many applications. I already use the script to launch tasks (when I detec change in the source). I don't think I'm alone to do this. Scripting is already used for other things that loading data.

Moreover, Qlik has already developed these API and this is a lot of work. Now, you have the opportunity to add a lot of value to the product with very few work.

Best regards,

Simon