fermata
fermata copied to clipboard
natevw
Succinct native REST client, for client-side web apps and node.js. Turns URLs into (optionally: magic!) JavaScript objects.
This dependency hasn't been working well for years, and hasn't been needed either since node.js has had native Proxy for almost as long. Having it generates lots of install noise...
Looking over #49 again it strikes me that perhaps folding the "method methods" (`.get(cb)`/`.put(data, cb)`/etc.) into the same namespace as the URL path components has sort of boxed us in...
The changes in 747f9e49d4333906cb01ec8a779ce9dbd485d5eb fixed #27 but should be reviewed before the release following that.
Having (optional?) support for promises will allow for even more elegant usage with libaries like co. Since fermata is already using es6 features, it wouldn't be too farfetched to either...
Most of the tests now simply cover URL handling only, and barely scratch the surface of all the transports/mixins themselves with all their nuances. Also, the tests succeed silently. They...
It'd be nice to have a canonical "include this script url" for Fermata.
While I still think most use cases will provide full requests and desire full responses, there's no reason this needs to be the only option at the transport layer. The...
The documentation could use another pass, especially focusing on: - General user-friendliness — does it make sense? are the right things emphasized? - Use of new features (streams, node/xhr options...
Couple things have felt awkward to me, especially in more casual use of Fermata: - for one-off requests, it's a little bummer that e.g. `fermata.json("http://localhost:5984/db/_changes", {limit:5})` doesn't work. Perhaps it...
See https://github.com/natevw/fermata/issues/25#issue-9749968 for example, where Fermata doesn't play nicely with an API that wants trailing slashes. Granted, in that case it'd be better (i.e. more performant!) to still deal with...