-
Notifications
You must be signed in to change notification settings - Fork 113
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
Move to Faraday #24
Move to Faraday #24
Conversation
I want to minimize the number of external dependencies this gem has, which is why I went the net/http route in the beginning. With your patch to #23, there shouldn't be much need for these other dependencies -- are there other issues that would be resolved by adding one of these gems? |
I should think that the lack of error detection and handling and write support could be much more easily remedied with Faraday. Also, parallel requests could be easily integrated with the Typhoeus adapter. |
One more point for Faraday: the JSON parsing middleware doesn't seem to have any Rails-related bugs. |
I'd be interested in seeing what the spike of this would look like, have you done any work towards this to see how involved it would be? |
+1, I'd also be interested in seeing a spike on this. |
Sorry, nothing yet. Should be pretty simple though. |
…el methods here and replacing complicated Net::HTTP logic with Faraday
I know two test suites right now, but it'll get better…
…different across platforms
I'm spiking on a new version of the gem, this include a client class like mentioned in #29 and using Faraday. Its on the faraday branch if you are interested. https://github.com/kytrinyx/etsy/tree/faraday |
Conflicts: etsy.gemspec
I really like this direction. I'll jump in tomorrow and add the pieces for authenticated requests. |
Seconded. I'll see if I can find a bit of time to help with this. |
I'm looking at the I could write specs against my own user, but I don't want to commit expected results to the repo. We could filter out the sensitive data in the same way that we filter out the API key, but then you couldn't delete the cassettes without knowing how to log in as me. Should we create a fake user and share the login amongst us? (not a very tempting proposition). Any suggestions? |
The way I've been doing it is filling in my own API key in the
|
If that doesn't make sense let me know |
It makes sense, but I'd rather not have to remember not to commit a change to a file that is already in source control. I'd rather |
No need to export. |
I'll push a change in a few minutes for the env variables
|
What do you think about this: 31d128b |
Oh, nice! |
@Muon do you see a need for a single |
No, no, this is fine. I was merely confused since there were |
Right now the way it works is a bit weird you have to use the access token
|
Basically there are a couple ways this would be used.
It might make sense to save the oauth token into instance variables when they're received and only have |
I agree
|
@kytrinyx what's left to do here, sorry been a bit disconnected lately
|
@trobrock I think the only thing left is to add support for nested resources:
|
@trobrock I've added the nested resources syntax to the query. If this all looks good, I'd suggest that we merge this in, deprecate the model stuff (but not rip it out yet), and bump the version to 0.3.0. Then when we're ready to remove the older syntax we can bump to 1.0.0. Would you have time over the next week or so to take the query syntax for a spin? |
Looks good to me, I will try this week or next to test out the syntax. I agree with the idea of one release with a deprecation, then completely remove it. |
* master: #53: add bought listings to user pass credentials #51: find admirers Inline the Etsy.host parameter in BasicClient add Roger Smith to README add more attributes to listing add more attributes to listing ability to create a favorite listing ability to create a favorite listing add buyer_id to transactions should be users/ not listings/ adding ability to retrieve a user's favorite listings Updating rake dependency for upcoming 0.9.3 release
When running the specs on jruby, srand is initialized incorrectly. Downgrading to rspec 2.7.x allows the specs to be run.
Currently, the gem is doing a lot of the HTTP work on its own, which might not be such a good idea (e.g. issue #23). Moving to Faraday would also take a good chunk out of the test code, and permit easier future extension. Thoughts and opinions?