-
Notifications
You must be signed in to change notification settings - Fork 321
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
Refactor or remove Response#parse
API
#538
Labels
Comments
/cc @httprb/core |
That sounds ok to me, so long as something like this works: .parse(:json) |
Yeah. That was my point we should remove implicitness of mime type argument. |
ixti
added a commit
that referenced
this issue
Mar 11, 2019
ixti
added a commit
that referenced
this issue
Mar 11, 2019
ixti
added a commit
that referenced
this issue
Mar 12, 2019
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
IMO
Response#parse
with implicit MIME-type guessed from response Content-Type must be discouraged:The snippet above will raise:
Although error message is clear, I don't see how this API can be good to use. Let's say one will define parser for
text/html
that will be returningNokogiri::Document
. So now,#parse
will be returningNokogiri::Document
if content type istext/html
,Array
orHash
if content type isapplication/json
... There's no way one will be able to work with that without some sort of wrapper (or just branching based on type) to neglect differences betweenNokogiri::Document
and plainArray
orHash
loaded from JSON.So probably we should make mime type argument required.
PS Users of Oj may find this API less performant than
Oj.load(res)
as latter one will utilize streaming.The text was updated successfully, but these errors were encountered: