Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: the ability to indicate content-type when the server does not provide it #92

Closed
ccp-ccollins opened this issue Aug 28, 2017 · 4 comments
Assignees
Labels

Comments

@ccp-ccollins
Copy link

Sometimes I am forced to get data from a server that has a consistent API (for example, it always returns JSON) but does not set the Content-Type header. In these cases, it appears that resty does not automatically parse the response automatically with SetResponse().

In cases where I know for sure what data should be expected, I'd like to be able to indicate that, rather than reading the body and parsing manually. For example, it could be something like this:

resty.R().
    SetResult(&output).
    ExpectContent("application/json").
    Get(url)
@jeevatkm jeevatkm self-assigned this Aug 29, 2017
@jeevatkm jeevatkm added this to the v1.0 Milestone milestone Aug 29, 2017
@jeevatkm
Copy link
Member

It seems nice addition to resty. Thank you, let me think of Content-Type fallback option for response and get back to you.

@jeevatkm
Copy link
Member

jeevatkm commented Sep 3, 2017

@ccp-ccollins I have added this feature. Available on branch expect-content-type f6639301f648551def9461e791a8b789e60fb9ee

Please give it try and share your feedback, then I will merge it to master. You can expect this feature in v1.0 release.

@jeevatkm
Copy link
Member

jeevatkm commented Sep 5, 2017

@ccp-ccollins whenever you get a chance, try and share your feedback. Thanks.

@jeevatkm
Copy link
Member

jeevatkm commented Sep 8, 2017

@ccp-ccollins Did you get a chance try it out?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

2 participants