
Facebook quietly deprecated their Python/Ruby libraries for Instagram API - tksohishi
https://github.com/facebookarchive/python-instagram
======
danso
Instagram is by far one of the easier APIs to use (among the social media
services)...I've never used a client library for it, in Python nor Ruby.

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/sferik/twitter)

[https://github.com/arsduo/koala](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.

------
cowholio4
As a user of the gem I can say it was effectively deprecated over a year ago.
I ended up just writing my own requests to do what I needed to do.

But at least they now give you a notice. :)

~~~
minimaxir
And the API end points are well-documented so it's not a big deal.

~~~
petetnt
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.

~~~
minimaxir
I'm not happy about the restrictiveness either. (Especially the new Sandbox
rate limitations)

~~~
cowholio4
Me neither but it seems like it's Instagram's attempt to stop the spammers.

Unfortunately, I have not seen a significant decrease in Instagram spam since
the changes. So the changes just hurt legitimate developers.

------
tksohishi
Ruby one: [https://github.com/facebookarchive/instagram-ruby-
gem](https://github.com/facebookarchive/instagram-ruby-gem)

------
stuartaxelowen
Because they are shallow layers over their REST API? There's nothing useful in
there anyway.

~~~
derefr
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.

~~~
bluk
I believe the current most popular flavor is Swagger (
[http://swagger.io](http://swagger.io) ) at the moment.

~~~
bpicolo
Despite having such quirks as: no Null support =|

~~~
encoderer
IME, especially building APIs for mobile apps: nulls suck anyway!

~~~
bpicolo
Yeah, but nonetheless, are sometimes necessary. The suggested way is to just
remove the field entirely, which is really a different sort of null.

Also, generic mapping types are second class citizens, id est just wanting to
specify string -> string

~~~
encoderer
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.

------
dmzza
This is the best looking fork that I could find, I haven't tried it yet.
[https://github.com/Aeon/instagram-ruby-
gem](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.

