HttpResponseMessage is hard to use.

[MicahZoltu]

https://github.com/aurelia/http-client/blob/master/src/http-response-message.js#L34-L61

It is difficult to write robust code when methods behave like this one. In particular, the part where it parses the json for you if the content-type is json. In my code, I have to now check the content type and branch according to it. This is especially true if running static analysis (TypeScript) since content can return either an object or a string.

I would prefer it if there were two methods, one for getting the raw content and another for getting the parsed content. For backwards compatibility reasons, I suppose this means two methods added: contentAsString and contentAsObject.

• contentAsString would only return me string content, regardless of the content-type.
• contentAsObject would only return me a deserialized JSON object if the content-type was json, it would throw in all other cases.

In general, it is pretty rare that someone doesn't know the content-type of the request they are processing so it is likely that the most desired behavior is a thrown error if the content isn't of the appropriate type (e.g., they get non-JSON when they asked for JSON).

[EisenbergEffect]

There is already a property called response which is the raw response. Is that good enought?

[MicahZoltu]

Ah, I didn't realize that is what response contained. Though, reading this suggests that XMLHttpRequest.response (which I am guessing is what xhr.response is) is potentially a deserialized response. Is one of my assumptions incorrect or am I missing something? It seems like what I want is xhr.responseText, but I'm not entirely sure.

Essentially I just don't want a union style return value (which unfortunately seems to be very common in JavaScript), it makes writing safe code difficult. If xhr.response will always be a string or an exception then that solves my problem.

[EisenbergEffect]

@Zoltu You may want to look at our new fetch plugin and see if that is more to your liking.