Interesting they choose JSONP (which is GET only, and can't return proper error codes) for such a POST-heavy library. It doesn't really matter, since they abstract it away. However, it's interesting they're completely ignoring so many basic REST principles.
Edit: I don't disagree with their decision, I just imagine it wasn't an easy one.
I'd rather have a functioning solution that "ignores basic REST principles" and lets me accept money from IE users than a principled library that requires the latest greatest browser to process transactions with.
It's not interesting, if you read the post you would know that they did it because of IE lacking support for CORS.
> Unfortunately, that’s not quite enough for Stripe.js. IE6 and IE7 both lack CORS support, while IE8 and IE9 have broken implementations. IE10 is the only version with a non-buggy CORS implementation. Obviously, compatibility is paramount for Stripe.js — we want to support all major browsers, right down to IE6—and so we needed to look elsewhere.
I'm not sure how common this is, but our application totally has a middleware to allow simulating other methods via _method and _body querystring parameters in GET requests. I know I've seen many other companies do this. Some may scoff at this for probably naive reasons, but REST doesn't have to mean 'correct' HTTP. It's just an architectural style.
Edit: I don't disagree with their decision, I just imagine it wasn't an easy one.