Should I use this gem? (vs. building HTTP requests)

[vemv]

Hi!

A reasonable FAQ is whether I should use this gem in the first place, as opposed to making HTTP requests myself using my favorite library (I like Faraday and looks like you'll be using it someday - #313)

My personal philosophy is to build HTTP requests myself unless there are strong reasons against. Are there such reasons in Stripe's case?

It would be great to summarize what this gems provide, and what to consider when choosing one option or the other, from Stripe's perspective. One point I particularly care about is possible API changes.

Cheers - Victor

[brandur]

Hey @vemv,

Good question. In my mind anyway, I'd say that because the Ruby client is such a dynamic affair, using it versus raw hash responses from an HTTP client is actually pretty similar in that in both cases you're largely dealing with schemaless objects. This tends to make the value proposition of the bindings somewhat more questionable. I think a few nice pieces that the bindings will get you though:

• Faster bootstrap. It knows how to send an API key and other basic things like that, which should allow you to get up and running more quickly.
• Built-in helpers for some mechanisms that you would otherwise might have to do yourself like pagination or parameter encoding (unfortunately, the Stripe API still uses application/x-www-form-urlencoded for request parameters, so you need to take a few precautions to make sure that you get this right).

A notable downside (in my opinion) is that as described in #313, the client doesn't currently allow you access to the underlying HTTP client. This has a few disadvantages:

• You're locked into the naive one-off request implementation that we have today. Connections cannot be re-used which means that you get the cost of the TLS setup on every operation.
• It makes instrumentation difficult.

I suspect that we'll be able to get around to tackling some of the downsides of the bindings relatively soon, which should result in a significant improvement in the developer experience around them compared to going with raw HTTP. But until then, it'll largely be a matter of preference.

Thanks for getting this discussion going! I'm closing this issue out for now, but let us know if you have any other questions/comments.

[vemv]

Hey @brandur, thanks for the complete answer - I wouldn't have expected less from you guys!

I consider my question answered. However I'd recommend to maintain these points in the README.

Cheers - Victor

[brandur]

I consider my question answered. However I'd recommend to maintain these points in the README.

@vemv Cool! Agreed that the README should provide a little more information here. Added some introductory text in 4ae867f.