Set response body for derived types

Overivew

This is a suggestion, not a bug. I can submit a PR one of these days,

Suggestion

1. Change Body to internal set/init for StringResponse and similar
2. Remove parameterized constructor
3. Change the if-else chain on ResponseBuilder:229 from

responseType == typeof(StringResponse)

to

typeof(StringResponse).IsAssignableFrom(responseType)

Version

Targeting 7.x branch

Thoughts

I know it’s not a necessary change, because there are existing workarounds. The one I’m currently using is to derive from ElasticsearchResponseBase and define my own Property, which is deserialized from ResponseBodyInBytes in the getter. However, I think It would be better the Body is handled internally, since a child of StringResponse it’s still a StringResponse, albeit a more derived one. And if you don’t intend to let people derive from them, they should be defined as sealed IMO.

What do you think?

[stevejgordon]

Thanks for the reply. We’d recommend you return ByteResponse and do any deserialisation from there. Consumers being able to derive from any of these base or specialised response types is not intended behaviour. I am including this on a worklist we have for the Transport work for v8. I’m going to close this issue as we won’t make this change for 7.x in this responsitory. Thanks for raising this though as it prompted me to revisit this area and will benefit the package going forward.

[achobanov]

Well, because it seems a good way to centralise the deserialization. I did use StringResponse’s body to start with and deserialized in my service method, but since ElasticsearchLowLevelClient allows for custom responses (i.e. its constrained to an interface), why not make one that handles it instead?