-
Notifications
You must be signed in to change notification settings - Fork 556
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
Response body can't be a hash #449
Comments
Please have a look at #427 If response body is declared as a hash, it's not clear what should the hash be encoded to. JSON, XML, or perhaps url params? Therefore WebMock expects you to stringify hash to expected encoding. I.e {a: b}.to_json |
(Sorry for the late response, and thanks for your reply.) I see, that makes sense. Maybe this should be mentioned in the Readme? |
I am not sure that makes sense. If a server is actually returning JSON as the body content, the code parsing can assume its a Hash content type, therefore calling JSON.parse(response) will fail if its already a Hash. So its seems to me that Webmock should be able to send that as the response body, especially when a content-type of 'application/json' is explicitly passed. |
"If a server is actually returning JSON as the body content" - which server do you mean? We are returning a stubbed response. This response will be passed through specific http client library internals. You can't expect these libs to handle Hash. WebMock would have to convert Hash declared in |
Would it not be best to use the headers content-type to determine whether to return JSON or XML? I am stubbing as so
but would prefer not to have to call JSON.parse(response_body) since that is not a step that is required in my code as JSON is implicitly declared. Maybe I am missing something though? FWIW, I am using Faraday to make the actual request. |
In case there is response content type declared it could work. Webmock would have to raise an error is case body is declared as a hash and headers are not declared. |
Most people will forget about headers. |
I don't think that is a problem to require a content-type when passing certain types of body content, since that is generally a good practice across http requests. Could i make a pull request for this functionality? |
I don't think it's a problem either, as long as user gets a clear error message explaining content type needs to be added if missing. |
Great, thanks! |
I support and encourage implementation of this feature. I'm surprised this isn't a more widespread issue. I've already encountered this issue on two separate occasions with two different web services. Most recently I needed to implement a work-around whereby I changed my response-parsing method to handle/convert the stubbed response strings when in reality outside of the test environment this extra handling would not be required. |
Doesn't support hashes in general Re: bblimke#449
I am running into this now. How is one supposed to mock a JSON response where the response is a hash? Not a JSON encoded string, but a hash. At the Ruby (Rails) layer the response is a hash in my real code, so it must also be in my test. |
HTTP response body is never a hash (there is no Hash content type). Your ruby HTTP client most likely does the response body parsing for you and converts is to a Hash. In order for your http client to know that the response body is JSON, you need to indicate that by the Content-Type header.
|
Thank you all for your answers, specially @joshuaswilcox and @bblimke. I was having issues with a spec for hours which mixed I'm leaving my solution here: stub_request(:get, /exampleurl.com/)
.to_return(
status: 200,
body: JSON.generate(response_json),
headers: {"Content-Type"=> "application/json"}
) |
Doesn't support hashes in general Re: bblimke#449
Why this PR? Right now, users might be confused as to why a hash cannot be accepted as a response body? See Issue bblimke#449 on Github as well as bblimke#427. This seems to have caused considerable consternation to API users - with some spending many frustrated hours searching for a solution. Perhaps it can be solved with a more helpful exception message? This PR hopes to remedy this apparent shortcoming. Perhaps I shall remedy it with an update to the documentation as well. I submit it with the utmost respect to the maintainers and community. Thank you for your efforts, and for reviewing. Ben
Thank you so much @bblimke @joshuaswilcox @dduqueti. Assuming stub_request(:get, /exampleurl.com/)
.to_return(
status: 200,
body: response.to_json,
headers: {"Content-Type"=> "application/json"}
) |
I think part of what makes this particularly confusing is that if you pass an empty hash, it doesn't throw an error. |
When I stub a request and specify a hash for the response body, I get the following error:
Is there a particular reason why it can't be a hash?
The text was updated successfully, but these errors were encountered: