Allow to set HTTP headers by key and value easily

[davsclaus]

Using restlet got a lot harder due setting and reading http headers uses a whole range of methods
https://restlet.com/technical-resources/restlet-framework/guide/2.3/core/http-headers-mapping

It would be good to have a normal single method as well where you can get or set a header using a key and value. And allows clients to not have a gazillion if .. else to figure out which restlet setter method to call for setting an Accept header etc.

Response response = ...
response.setHeader("Content-Type", "application/json");
...

Then you can under the hood do the dancing and figure or what to do on behalf of the client.

Its really tiresome to have to add a gazillion if else and whatnot logic to be able to support all those restlet http header methods.

[davsclaus]

The same for request, to be able to easily get the header as well.

[jenkins-restlet]

You have a getHeaders() method on Request/Response but it prevents you from
overriding standard headers when they exist.
On Feb 25, 2016 8:36 AM, "Claus Ibsen" notifications@github.com wrote:

The same for request, to be able to easily get the header as well.

—
Reply to this email directly or view it on GitHub
#1198 (comment)
.

[davsclaus]

Well we have other time had troubles with restlet at Apache Camel because of changes in restlet itself causing old code to no longer work that was using a "generic" get/set.

Also the generic way is deprecated and you got some WARN logs.

Now we are tired of having to add a gazillion if ... elseif ... elseif ... to be able to set or get the headers.

And we have reports from end users complaining restlet not working with their headers etc.

[thboileau]

linked to #1086 also.

[thboileau]

@jlouvel what is your thinking about that point?

[jlouvel]

It's clearly painful for devs who have to deal with raw headers as they need to dispatch those to the Java API for standard header.

I think we should relax that restriction. The initial goal was to inform and encourage the use of the higher level Java API when it exists. But there are use cases like Camel where this is counter-productive.

We could change this rule in RF v2.4 by considering that a header set via getHeaders() should take precedence or the equivalent Java API and not trigger a warning but only a FINE trace or similar.

@davsclaus Would that work for you? Do you have a pointer to the gazillion if/else code so that we ensure the update behavior removes your issues?

[davsclaus]

@jlouvel +1

I think its a good idea you have.

If I was writing a non Camel application and are using Restlet as REST client etc, then the higher level API makes sense as they are more type-safe etc.

So your idea of allowing both worlds is good imho. There is likely other libraries besides Camel that uses Restlet for REST that can benefit as well.

[jlouvel]

Thanks for the feed-back.
@thboileau do you see any issue if we relax the current rule?

I think we mostly need to refactor the addExtensionsHeaders(...) into an overrideHeaders(..) one in this class:
https://github.com/restlet/restlet-framework-java/blob/master/modules/org.restlet/src/org/restlet/engine/header/HeaderUtils.java

[thboileau]

Hi @jlouvel , @davsclaus no problem for me to relax the rule.

[thboileau]

planned for 2.4