Ability to prefix each RestTemplate request using some kind of UriPrefixingClientHttpRequestFactory [SPR-13035]

[spring-projects-issues]

Jiri Mikulasek opened SPR-13035 and commented

Please consider to provide some way how to prefix all requests from RestTemplate with the same basic prefix (usually protocol://host:port/someapiprefix form).

I believe this use case is pretty widespread as people uses RestTemplate to implement custom client libraries for apis, which resides on the same prefix quite often.

If there already is such possibility, please point me the right direction. Otherwise I would love to cooperate on inclusion (and possible improvements) of our UriPrefixingClientHttpRequestFactory and UriPrefixer into springframework

---

Issue Links:

• Add constructor base address in RestTemplate [SPR-7803] #12459 Add constructor base address in RestTemplate ("is duplicated by")
• UriTemplateHandler is not called for requests without url variables [SPR-13145] #17736 UriTemplateHandler is not called for requests without url variables

Referenced from: commits 1ba0625

[spring-projects-issues]

Rossen Stoyanchev commented

I think the recent change to add a UriTemplateHandler might be a good fit. See comment here.

[spring-projects-issues]

Jiri Mikulasek commented

Yes, the DefaultUriTemplateHandler can be the way. But the current implementation (as seen in code has no possibility to setup some prefix, which is used for each request using restTemplate with such handler. To be exact, my point is not to have to use the same protocol://host:port/someapiprefix string in every URL I passes to restTemplate, but rather use URLs starting after that common prefix.

I can imagine to implement prefixing mechanism as UriTemplateHandler extending that Default one or simply add such functionality into the DefaultUriTemplateHandler. In addition I think this deserves to be implemented inside springframework - so if you agree I can code one of those variants.

If you believe this usecase is too specific to be covered in framework, we can live with our implementation quite well.

[spring-projects-issues]

Jiri Mikulasek commented

Sorry, now I realized, you proposed to setup the prefix using UriTemplate for each request - yep it is definitely possible, but doesn't fit my usecase very well. (Developing client for API of specific vendor - so all my requests goes to the same host/prefix - so to setup host over and over doesn't help much). Hopefully now I clarified this thing better.

[spring-projects-issues]

Rossen Stoyanchev commented

Can you provide an example of what URL do you want the code using the RestTemplate to pass and how it should be modified by the time the final URI is ready?

[spring-projects-issues]

Jiri Mikulasek commented

Ok let's assume I would like to code client library to my API which is in real life deployed at two or more distinct servers (like two separate environments). So the library must be configured to be used with specific host.

Without the UriPrefixing functionality covered by RestTemplate, I can cope with that i.e. like this:

public class MyApiClient {
    private final String host;
    private RestTemplate template;
    public MyApiClient(String host) {
        this.host = host;
        this.template = new RestTemplate();
    }

    public String getSomeApiResource() {
        return template.getForObject(host + "/myapiresource", String.class);
    }
}

With the UriPrefixing functionality

public class MyApiClient {
    private RestTemplate template;
    public MyApiClient(String host) {
        this.template = new RestTemplate(new UriPrefixingClientHttpRequestFactory(
                new HttpComponentsClientHttpRequestFactory(client), host));
    }

    public String getSomeApiResource() {
        return template.getForObject("/myapiresource", String.class); // automatically prefixed with host
    }
}

Well in short example it doesn't look like evil to prefix the host over and over in each method using RestTemplate- but it gets annoying soon (not even talking when the api is huge and you have several classes to cover it. That's why we developed this UriPrefixing thing and as we want to move to spring4 we realized, that it can be useful (somehow) to other people - this is what this ticket is about.

I don't insist on implementing it the same way we did, but I can't see how could DefaultUriTemplateHandler help me.

If you are still unsure what's on my mind, please take a look at our library code - hopefully it will help you to get the point. However if you decide this is way too specific for framework, I'm fine with that and can keep my solution.

[spring-projects-issues]

Rossen Stoyanchev commented

Indeed DefaultUriTemplateHandler in its present form can't help. I never meant that but rather UriTemplateHandler as a mechanism that you can use. That said I can certainly see support for a baseUrl in DefaultUriTemplateHandler as something generally useful. That's what you had in mind?

[spring-projects-issues]

Jiri Mikulasek commented

Yes DefaultUriTemplateHandler.baseUrl is definitely suitable way how to satisfy this requirement. Moreover to me it seems as more appropriate than our UriPrefixing....Factory.

[spring-projects-issues]

Rossen Stoyanchev commented

I've added a baseUrl property (see commit 1ba062). If you can please give it a try and confirm that it meets your use cases.

[spring-projects-issues]

Jiri Mikulasek commented

Thank you, this looks suitable to our use cases.

[spring-projects-issues]

Rossen Stoyanchev commented

Thanks for confirming!

[spring-projects-issues]

Jiri Mikulasek commented

It appeared that I missed one point when verifying - the UriTemplateHandler is called by RestTemplate only when some url variables are passed, so when I use the handler to prepend uris with same base, it doesn't apply for cases tihout variables. This is I think wrong.

Unfortunately it seems this ticket cannot be reopened. Should I write BUG for this?

[spring-projects-issues]

Rossen Stoyanchev commented

Yes we close tickets once a release is out since we can never undo the release. Please open a new ticket.