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

format is not taken into account #131

Open
kspeeckaert opened this issue Jul 5, 2016 · 1 comment
Open

format is not taken into account #131

kspeeckaert opened this issue Jul 5, 2016 · 1 comment

Comments

@kspeeckaert
Copy link

Resource.__call__() has an argument format, that should be used to get the correct content type and add it to the headers when performing the request.

If you look at the code for Resource._request(), it set the accept header to the correct content type by executing serializer.get_content_type(). However, the value passed to format (which is stored in self._store['format']), is not passed to the get_content_type() function, which causes get_serializer() to return the default serializer. This in turn will cause the accept header to be set to the content type of the default serializer.

TL;DR:

  • The format option isn't used
  • The default format specified when creating the API object will always be used to set the accept header (defaults to JSON).
amureki added a commit to thermondo/slumber that referenced this issue Aug 22, 2018
Documentation page https://slumber.readthedocs.io/en/v0.6.0/options.html#serializer says
that we can define certain format for each resource, but this was not taken into an account.
PR adds this behaviour and fixes samgiles#131.
@amureki
Copy link

amureki commented Aug 22, 2018

@kspeeckaert greetings! We've made a fork and PR fixing this (but no tests covering this yet).
But I don't know if this package is still maintained.

@samgiles can we reach you out?

Upd.: added test (I am not sure about styling though)

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

Successfully merging a pull request may close this issue.

2 participants