Pass an object as an argument to customer.list and coupons.list

[kc-dot-io]

This is somewhat of situational PR but I think it's worth considering for the sake of consistent alignment of arguments.

I have some code that is looping through the charge, customer and invoice endpoints, making calls to list methods programmatically. It seems that the expected arguments for charge and invoice both accept an object however customer expects two separate arguments for count and offset. This PR just adds support for the short hand .list({ count: x, offset: x}, fn) arg style which makes for a slightly more consistent interface across these methods.

Side note, I ran the tests before writing this PR and they seem to fail for me, so I wasn't able to confirm this PR against the tests. This could be due to the fact I was testing with a stripe connect oauth key but I'll do some work on the tests and see what I can figure out.

I've also got some reasons to implement more support for connect so I'll see what help I can offer there in future PR's.

Feedback appreciated.

[abh]

Yeah, I think the API should have been setup so only "primary key"-type paramaters are "bare" and everything else should have been an object (for "options").

If we're cleaning it up we should do it for all the functions though (with backwards compatibility, documentation and tests).

Maybe some utility function to help sort it out; a bunch of if () statements like you have in this patch will end up being a bit ugly and unmaintainable, I think.

[kc-dot-io]

That's good feedback. I'll try to implement it. Can you give examples of what you consider "primary key" type parameters? My presumption would be things like id are required and therefor are arguments where as offset and count are optional and would be passed via a object.

[kc-dot-io]

@abh - I added a function to normalize arguments for each of the list methods that it made sense to. It should be backwards compatible. I left charges.list, invoices.list and events.list alone because they are already passing the entire object so there is no backwards compatibility concerns. I also updated the documentation and ensured the tests pass:

slajax@slajax-desktop:~/repos/node-stripe $ STRIPE_API=XXX vows test/*
···· ····· · ········ ······ ··
  ✓ OK » 26 honored (16.687s)

Hopefully this is a little more along the lines of what you were looking for. Let me know what you think.

Also, to your knowledge is anyone working on the invoice/pay method? If not I'll take a stab at it later this week.

[abh]

I like it; thank you!

Don't think there's anything for invoice/pay in the queue, so go crazy. :-)