I'm surprised this hasn't been trivialized/automated away yet (or has it?) Some sort of language-neutral REST-protocol description language, that could be used to code-generate client libraries and also generate a test spec and documentation. Or maybe just a standard for media-types in HATEOS response types in specifying REST API "roots", to make them machine-discoverable, in a way where the result could be "cached into" a client-library.
I appreciate your point of view, but mine is different. For example, at Trulia, with a dozen different apps with millions of users and rich data in the app, there is a "no nulls" policy. It's just a convention: build sparse data structures instead of passing nulls.
So messing around with Python and rest APIs... Often a wrapper library for an API exists on github.. But why use it? If I use 6 APIs in my project I now just added 6 libraries that all do things like auth, connection pooling, error handling a little bit different. Meh. The actual work of code to json to API to json to code is simple (1 line usually), I would rather just learn the API and do it myself. You still need to learn the API to use the wrapper library...
This is a shameless plug, so I'll take my beating if it's appropriate. For the last few months, I've been working on a Python library, beekeeper, that's all about that. It essentially consumes a JSON description file that gives all the specs for an API, as well as information about its object structure, and then provides an intuitive, native-Python interface, typically with little to no additional code required.
I feel like abstracting APIs into objects (essentially RPC calls?) creates too much of a dependency on the network. The friction of writing the calls and their handlers helps minimize their use :)
So what is consensus on client libraries like this? Personally, I'd rather just use my own calls. Aren't most RESTful APIs simple enough not to need such libraries? And if they're not, it's a design failure?
But then you have companies like Braintree that only supports its libraries?
A good client library should abstract away the rate limiting, at least.
That is, it should keep track of how many requests you made over time, and if making another will put you over the rate limit, the library should block for however much time is needed before actually sending the request.
For example, I can't imagine interacting with Reddit's API without praw taking care of the rate limiting for me.
Enterprise clients (the ones they care about) are likely making requests from multiple machines, meaning you have to track API usage per token in a database somewhere.
I wanted to do something with the Instagram API few weeks ago and it kinda surprised me how restrictive it is. You cannot do nearly anything without authentication and everything else is restricted by the TOS.
Most sites build their anti-DDoS logic around per-user rate limits. This requires them to force all API requests—even ones for completely public data—through a user session, to give those requests a context to be rate-limited by.
Allowing 'anonymous, public' APIs either requires that you rate-limit either too conservatively (e.g. by client ID—so clients with more users hit rate limits) or too liberally (e.g. by IP—so truly malicious clients can just hit you with a botnet.)
The only good way to provide a registration-less public API boils down to pairing—effectively "registering the machine" by handing it a token, and then relying on supercookies or frequently-revalidated 2FA tokens to persist the session. But this only works if you can reasonably expect a person to only want to query your API from one device at a time. If there are real use-cases for which your clients will want to hit you from random new machines (e.g. CoreOS's hosted etcd) then pairing won't help you.
The koala gem for Facebook is a godsend...the FB API and models are not trivial...and that's before trying to keep up with the many and frequent changes to the API spec. It's hard to imagine that FB would put the resources into continually maintaining that gem if it were an official gem...not when (I assume) so many more of their API consumers use iOS/JS/Android.
This is the best looking fork that I could find, I haven't tried it yet. https://github.com/Aeon/instagram-ruby-gem
I hope Facebook gives write access to a volunteer to merge some of these pull requests.
I wonder if the whole API is slowly on the path to deprecation.
29 comments
[ 2.9 ms ] story [ 73.9 ms ] threadAlso, generic mapping types are second class citizens, id est just wanting to specify string -> string
You can check it out on GitHub at https://github.com/haikuginger/beekeeper, read more at http://beekeeper.rtfd.org, or just install it with pip.
I'm biased, but I think it's pretty cool.
I feel like abstracting APIs into objects (essentially RPC calls?) creates too much of a dependency on the network. The friction of writing the calls and their handlers helps minimize their use :)
Disclosure: I'm a top contributor to Swagger-Codegen
But then you have companies like Braintree that only supports its libraries?
That is, it should keep track of how many requests you made over time, and if making another will put you over the rate limit, the library should block for however much time is needed before actually sending the request.
For example, I can't imagine interacting with Reddit's API without praw taking care of the rate limiting for me.
But at least they now give you a notice. :)
Allowing 'anonymous, public' APIs either requires that you rate-limit either too conservatively (e.g. by client ID—so clients with more users hit rate limits) or too liberally (e.g. by IP—so truly malicious clients can just hit you with a botnet.)
The only good way to provide a registration-less public API boils down to pairing—effectively "registering the machine" by handing it a token, and then relying on supercookies or frequently-revalidated 2FA tokens to persist the session. But this only works if you can reasonably expect a person to only want to query your API from one device at a time. If there are real use-cases for which your clients will want to hit you from random new machines (e.g. CoreOS's hosted etcd) then pairing won't help you.
Unfortunately, I have not seen a significant decrease in Instagram spam since the changes. So the changes just hurt legitimate developers.
In Ruby, the best API wrappers (or at least, the ones I used back in the day) for Twitter and Facebook are maintained independently:
https://github.com/sferik/twitter
https://github.com/arsduo/koala
The koala gem for Facebook is a godsend...the FB API and models are not trivial...and that's before trying to keep up with the many and frequent changes to the API spec. It's hard to imagine that FB would put the resources into continually maintaining that gem if it were an official gem...not when (I assume) so many more of their API consumers use iOS/JS/Android.