HTTP method print

Rob Jansen

Hi,


we are working on an interface with a system that has a rather stubborn API. At the moment I am trying to get qoutes as PDF and store them under a sale. The API has an endpoint for this and returns a json with base64 encoded PDF which is nice.  
However the method used is PRINT. In RestSharp a request would look something like 

var client = new RestClient("https://server/api/rest/data/offerte/43");
var request = new RestRequest(Method.PRINT);
IRestResponse response = client.Execute(request);

In CRMScript I only have delete, patch, post and get as far as I know. Like

HTTP httpClass;
httpClass.addHeader("Content-Type", "application/json");
NSStream responseAsStream = httpClass.getAsStream(url); //here's a problem...
String rawJSONResponse = String(responseAsStream);

Is there something I missed or is this not possible?

Thanks,

Rob Jansen


 

 

STAFF /de/My-Page/5703/

RE: HTTP method print

We do not support any other verbs than GET, POST, PUT, PATCH and DELETE through CRMScript.

That being said, I have never heard of the verb PRINT being used before. Also looking into the RestSharp documentation, there is no enum on Method that is called PRINT: https://restsharp.dev/api/RestSharp.html#enum-method

Von: Stian Andre Olsen 16. Dez 2020
PARTNER /de/My-Page/11000/

RE: HTTP method print

Hello Stian,

Thanks for your response. We know it is not an standard verb, but it is an external API that we can't change so we have to deal with it...

Von: David Hollegien 16. Dez 2020
STAFF /de/My-Page/5703/

RE: HTTP method print

I see.

The only options I see is:

1) Creating a proxy service, in for example Azure that can do this PRINT http call, and then you call on this service again from CRMScript using one of the supported verbs.

2) Register a wish for the HTTP class in CRMScript to support custom verbs.

 

Von: Stian Andre Olsen 16. Dez 2020
PARTNER /de/My-Page/11000/

RE: HTTP method print

Hello Stian,

Thanks, just send an email to register a wish. In the mean time we are propably going for #1 if we can't get the external party to fix their 'API'.

Von: David Hollegien 16. Dez 2020