22 Commits

Author SHA1 Message Date
Brandur
863da48398 Add frozen_string_literal to every file and enforce Rubocop rule
Adds the magic `frozen_string_literal: true` comment to every file and
enables a Rubocop rule to make sure that it's always going to be there
going forward as well.

See here for more background [1], but the basic idea is that unlike many
other languages, static strings in code are mutable by default. This has
since been acknowledged as not a particularly good idea, and the
intention is to rectify the mistake when Ruby 3 comes out, where all
string literals will be frozen. The `frozen_string_literal` magic
comment was introduced in Ruby 2.3 as a way of easing the transition,
and allows libraries and projects to freeze their literals in advance.

I don't think this is breaking in any way: it's possible that users
might've been pulling out one of are literals somehow and mutating it,
but that would probably not have been useful for anything and would
certainly not be recommended, so I'm quite comfortable pushing this
change through as a minor version.

As discussed in #641.

[1] https://stackoverflow.com/a/37799399
2018-05-10 14:56:14 -07:00
Olivier Bellone
e02ff7f849
Start using RuboCop for linting 2017-09-27 21:28:25 +02:00
Corey Farwell
c4c38d63fc Add string constants for each of the Stripe object names. 2017-04-26 14:20:22 -04:00
Brandur
1886d9a625 Move to an alternative system based on StripeClient 2017-02-14 12:17:37 -08:00
Brandur
593bbab53f Use unambiguous wording "StripeResponse object" instead of "structure" 2017-02-14 12:17:37 -08:00
Brandur
843ea88219 Add a StripeResponse to objects created by API calls 2017-02-14 12:17:37 -08:00
Brandur
0311b4a7cd Fix reference to URLs on ListObject
In #394 we renamed `url` to `resource_url` in order to prevent name
collisions in API resource that also have a `url` property.
Unfortunately, this didn't account for the fact that when making API
calls on a list object we rely on a returned `url` property to build a
request, and this had been renamed to `resource_url`. Test should have
caught this, but they were written to work differently than how live
API calls actually function.

This patch repairs the problem by adding a `resource_url` to list
objects, and modifies test to be more accurate to reality so that
they'll catch this class of problem in the future.

Fixes #395.
2016-03-14 06:52:26 -07:00
Joshua Kovach
e226ef2ea1 Change everything from url to resource_url 2016-03-11 02:53:50 -05:00
Ryan T. Hosford
0acf314e30 ListObject extends ApiOperations::Create
- Addresses a bit of duplication.
2016-01-05 22:52:33 -06:00
Brandur
daf2789ad7 Pass through all paging filters to descendent pages
When additional filters were provided for pagination like an expansion
or a predicate, they would not propagate to any call after the first.
This patch addresses that issue by storing all filters and moving them
to any new page objects being created.

Fixes #331.
2015-10-09 13:58:23 -07:00
Brandur
42ea34b969 Pagination
Usage on a top-level collection:

```
Stripe::Customer.list.auto_paging_each do |customer|
  puts customer
end
```

Usage on a subcollection:

``` ruby
customer.invoices.auto_paging_each do |invoice|
  puts invoice
end
```

We've also renamed `#all` to `#list` to prevent confusion ("all" implies
that all resources are being returned, and in Stripe's paginated API
this was not the case). An alias has been provided for backward API
compatibility.

Fixes #167.

Replaces #211 and #248.
2015-10-05 12:15:09 -07:00
Brandur
af72a57c9d Add #empty? helper on ListObject
This makes ListObject behave a little more like an Array in that it gets
an #empty? helper. This should fit pretty well with the Enumerable
methods that it already has.

Replaces #193.
2015-09-30 13:13:41 -07:00
Brandur
5515824fe2 Mix Enumerable into ListObject
This pulls the `Enumerable` mixin into `ListObject`. There is some
question in pulls like #167 as to the future of `ListObject` and how it
might change when pagination is introduced, but because we're unlikely
to make any backward incompatible changes to the API, it's likely that
`ListObject` will continue to represent a page of data that's been
extracted from the API. Given that assumption, pulling `Enumerable` in
should be relatively safe.

Fixes #227.
2015-09-29 22:26:00 -07:00
Andy Cohen
97c9249ab1 extract method 'normalize_id' from 'StripeObject#initialize' & 'ListObject#retrieve' 2015-07-27 15:47:16 -05:00
Andy Cohen
31ccf7c6d3 fix #223 support expansions when retrieving via ListObject 2015-07-27 15:45:45 -05:00
Brian Krausz
4d611c62f7 Support persisted use of Stripe-Account header everywhere
Including implicit use in /v1/accounts/ endpoints
2015-02-09 23:38:34 -08:00
Kyle Conroy
e3a68bb3b9 Replace api_key with an options hash
For now, only two options are supported: `api_key` and
`idempotency_key`. In the future, we'll be adding support for additional
headers as needed.
2014-12-17 23:23:46 -08:00
Shale Craig
7c6c8269c6 Add ability to specify custom headers for list_object.create 2014-12-16 15:46:08 -08:00
Sheena Pakanati
87604d945e Initial support for multiple cards. 2013-07-11 16:47:58 -07:00
Evan Broder
1fbce5288c Add a more helpful error message to ListObject#[]
Our list calls return their results wrapped in an object so that we
can include extra information. We use this, e.g., to include the URL
to query for more records in the Transfer#transactions sublist.

When you get a ListObject, if you want to actually manipulate it as a
list, you have to call `#data` first to get the actual underlying
list.

This adds an exception to the `#[]` method to make what's going on
clearer.

Fixes #68
2013-06-30 23:00:01 -07:00
Evan Broder
daafdb983d Fix confusion in ListObject around where api_key was coming from
Fixes #69
2013-06-30 22:34:30 -07:00
Ross Boucher
7f87b2bc4a Add support for list objects. Bumps version to 1.7.5 2012-10-25 19:42:23 -07:00