adds asJsonString. Experimentally adds asStream and asBytes

[jesperfj]

This is a proposal to address #47.

It also adds an asStream() and asBytes() method to potentially address #55.

Looking forward to comments. Does this work for you @holtonma and @aduston?

[jesperfj]

There is only a crude test for asJsonString() at this point. The other two new methods are experimental and would need some tests to make it into a release.

[aduston]

It will work, but it might be awkward. What is a ResourceRepresentation? Is it a JSON object or a wrapper for any response from the API? The only public method in ForceApi that returns a ResourceRepresentation sets an Accept header of application/json, which contradicts the idea that this should be used for just getting bytes of file content data from the API.

If you wish to try this out first hand, try accessing the Body of an Attachment or the VersionData of a ContentVersion using this library with these changes.

[jesperfj]

I see what you are saying. I have held it as principle so far to not expose the http classes in the public api and I like the idea of ResourceRepresentation as the single class representing response content. But this is of course all subjective. Having get() only accept json is clearly not right. I'll take a look at that.

[aduston]

not expose the http classes in the public api

FWIW, another option you have is to create a different class that just wraps raw file responses. It would expose an InputStream and perhaps nothing else. Then your API will return two types of things: ResourceRepresentations and Data (or whatever you name it -- Salesforce calls the field "Body" for Attachment and Document, and VersionData for ContentVersion). This would avoid exposing the http classes, but might make the design less awkward.

Thanks for the library, btw.