7bbc6ef2e5
Prior to my last major serialization refactor, there was a check in the
code that would remove any subobjects from serialization that were of
their own proper resource type (for example, if a charge contained a
customer, that customer would be removed).
What I didn't realize at the time is that the old serialization code had
a bug/quirk that would allow *certain types* of subobjects that were API
resources to make it through unscathed.
In short, the behavior requirement here is *directly* contradictory.
There was a test in place that would make sure that `customer` was
removed from this hash:
``` ruby
{
:id => 'ch_id',
:object => 'charge',
:customer => {
:object => 'customer',
:id => 'customer_id'
}
}
```
But, as reported in #406, we expect, and indeed need, for `source` (a
card) to make it through to the API in this hash:
``` ruby
{
:id => 'cus_id',
:object => 'customer',
:source => {
:object => 'card',
:id => 'card_id'
}
}
```
My proposal here is to just remove the check on serializing API
resources. The normal code that only sends up keys/hashes that have
changed is still in place, so in the first example, `customer` still
isn't sent unless the user has directly manipulated a field on that
subobject. I propose that in those cases we allow the API itself to
reject the request rather than try to cut it off at the client level.
Unfortunately, there is some possibility that removing those API
resources is important for some reason, but of course there's no
documentation on it beyond the after-the-fact post-justification that I
wrote during my last refactor. I can't think of any reason that it would
be too destructive, but there is some level of risk.
Stripe Ruby Bindings 
The Stripe Ruby bindings provide a small SDK for convenient access to the Stripe API from applications written in the Ruby language. It provides a pre-defined set of classes for API resources that initialize themselves dynamically from API responses which allows the bindings to tolerate a number of different versions of the API.
The bindings also provide other features. For example:
- Easy configuration path for fast setup and use.
- Helpers for pagination.
- Tracking of "fresh" values in API resources so that partial updates can be executed.
- Built-in mechanisms for the serialization of parameters according to the expectations of Stripe's API.
Documentation
See the Ruby API docs.
Installation
You don't need this source code unless you want to modify the gem. If you just want to use the Stripe Ruby bindings, you should run:
gem install stripe
If you want to build the gem from source:
gem build stripe.gemspec
Requirements
- Ruby 1.9.3 or above.
- rest-client
Bundler
If you are installing via bundler, you should be sure to use the https rubygems source in your Gemfile, as any gems fetched over http could potentially be compromised in transit and alter the code of gems fetched securely over https:
source 'https://rubygems.org'
gem 'rails'
gem 'stripe'
Development
Run all tests:
bundle exec rake
Run a single test suite:
bundle exec ruby -Ilib/ test/stripe/util_test.rb
Run a single test:
bundle exec ruby -Ilib/ test/stripe/util_test.rb -n /should.convert.names.to.symbols/
Update bundled CA certificates from the Mozilla cURL release:
bundle exec rake update_certs
Configuration
ca_bundle_path
The location of a file containing a bundle of CA certificates. By default the library will use an included bundle that can successfully validate Stripe certificates.
max_network_retries
When max_network_retries is set to a positive integer, stripe will retry
requests that fail on a network error. Idempotency keys will be added to post
and get requests to ensure the safety of retrying. There will be a short delay
between each retry, with an exponential backoff algorithm used to determine the
length of the delay. Default value is 0.
Example:
Stripe.max_network_retries = 2