CRISP - cannot send headers in GET calls

Experience Manager (PaaS/OnPrem)
1

I am performing a GET call using CRISP passing two parameters in the header, but they are ignored.
Debugging the code I have seen the following in SimpleJacksonRestTemplateResourceResolver, line 77:

if (HttpMethod.POST.equals(httpMethod)) {
result = restTemplate.postForEntity(this.getBaseResourceURI(baseAbsPath), requestObject, String.class, pathVariables);
} else {
result = restTemplate.getForEntity(this.getBaseResourceURI(baseAbsPath), String.class, pathVariables);
}

The “requestObject”, the object containing the headers set using ExchangeHintBuilder as written in the documentation here https://documentation.bloomreach.com/library/concepts/crisp-api/getting-started.html is only passed if the call is in POST, while it is ignored in all the other cases.
I have composed the request like the following:

ResourceServiceBroker broker = CrispHstServices.getDefaultResourceServiceBroker();
ExchangeHint headers = ExchangeHintBuilder.create()
.methodName(“GET”)
.requestHeader(“email”, "test-email@gmail.com")
.requestHeader(“password”, “04ba23a976b4da6ae873c9830f73aace6c3162cb”)
.build();

Resource loginHash = broker.findResources(“crisp-resource”, “path”, headers);

Is there a workaround to do it or can it be fixed?

Thanks

2

Hi,
using headers in GET requests is not following the standard.

But you can write your custom ResourceResolver and pass headers while sending the request [1].

HTH,
Giacomo

[1] https://documentation.bloomreach.com/library/concepts/crisp-api/configuring-crisp-addon.html

3

Use #resolveBinary(...) [1] instead and parse the Binary output to JSON by yourself.
As Spring RestTemplate doesn’t support headers in get*() methods for the reasons based on http specification, CRISP doesn’t support it either by default. But I think #resolveBinary(...) passes all including headers and body if available. That will do the workaround.

Regards,

Woonsan

[1] Getting Started - Bloomreach Experience Manager (PaaS/Self-Hosted) - The Fast and Flexible Headless CMS

4

Thank you Woonsan, I confirm that I managed to perform that call

5

Thanks for updates, Flavio!
I’m thinking that we could improve a small thing but useful: we can perhaps add #resolveBinaryAsResource(...) to return a parsed Resource object instead of Binary, assuming the caller knows the return must be either JSON or XML.
Then it might be more useful in many cases. How does it sound?

Woonsan

6

Hi Woonsan,
yes I agree it would be great and coherent with the other methods return type
Thanks!

7

All right. I’ve filed a ticket:

Thanks,

Woonsan