Facebook quietly deprecated their Python/Ruby libraries for Instagram API

#1

Post by tksohishi » Fri, Apr 08, 2016, 9:44 PM UTC

Facebook quietly deprecated their Python/Ruby libraries for Instagram API
github.com

Re: Facebook quietly deprecated their Python/Ruby libraries for Instagram API

#2

Post by tksohishi » Fri, Apr 08, 2016, 9:46 PM UTC

Ruby one: https://github.com/facebookarchive/instagram-ruby-gem

Re: Facebook quietly deprecated their Python/Ruby libraries for Instagram API

#3

Post by stuartaxelowen » Fri, Apr 08, 2016, 10:43 PM UTC

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

Re: Facebook quietly deprecated their Python/Ruby libraries for Instagram API

#4

Post by cowholio4 » Fri, Apr 08, 2016, 10:51 PM UTC

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. :)

Re: Facebook quietly deprecated their Python/Ruby libraries for Instagram API

#5

Post by minimaxir » Fri, Apr 08, 2016, 11:03 PM UTC

cowholio4 wrote: post #4

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. :)

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

Re: Facebook quietly deprecated their Python/Ruby libraries for Instagram API

#6

Post by petetnt » Fri, Apr 08, 2016, 11:14 PM UTC

minimaxir wrote: post #5

cowholio4 wrote: post #4

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. :)

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

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.

Re: Facebook quietly deprecated their Python/Ruby libraries for Instagram API

#7

Post by cmdrfred » Fri, Apr 08, 2016, 11:24 PM UTC

petetnt wrote: post #6

minimaxir wrote: post #5

Earlier quoted context omitted.

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

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.

As far as I know that seems to mimic the site itself, you can't do very much without being signed in.

Re: Facebook quietly deprecated their Python/Ruby libraries for Instagram API

#8

Post by derefr » Fri, Apr 08, 2016, 11:33 PM UTC

stuartaxelowen wrote: post #3

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

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.

Re: Facebook quietly deprecated their Python/Ruby libraries for Instagram API

#9

Post by derefr » Fri, Apr 08, 2016, 11:35 PM UTC

petetnt wrote: post #6

minimaxir wrote: post #5

Earlier quoted context omitted.

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

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.

Re: Facebook quietly deprecated their Python/Ruby libraries for Instagram API

#10

Post by bluk » Fri, Apr 08, 2016, 11:51 PM UTC

derefr wrote: post #8

stuartaxelowen wrote: post #3

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

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 i…

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