Facebook quietly deprecated their Python/Ruby libraries for Instagram API • Hacker News Board

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

#21

Post by tomc1985 » Sat, Apr 09, 2016, 4:02 AM 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…

Honestly, unless the API is complex, why bother?

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

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

#22

Post by amyjess » Sat, Apr 09, 2016, 4:38 AM UTC

stuartaxelowen wrote: post #3

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

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.

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

#23

Post by cptn_brittish » Sat, Apr 09, 2016, 5:29 AM 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…

Sounds like the soap protocol. I've had to deal with it recently at work and paired with the suds python library auto generates the api for you

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

#24

Post by derefr » Sat, Apr 09, 2016, 8:13 AM UTC

tomc1985 wrote: post #21

derefr wrote: post #8

Earlier quoted context omitted.

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…

Honestly, unless the API is complex, why bother? 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 :)

Mainly because I code microservices in at least five languages, and want to be able to touch all the same third-parties from any given one of them.

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

#25

Post by bpicolo » Sat, Apr 09, 2016, 3:41 PM UTC

encoderer wrote: post #20

bpicolo wrote: post #19

Earlier quoted context omitted.

Despite having such quirks as: no Null support =|

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

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

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

#26

Post by cowholio4 » Sat, Apr 09, 2016, 4:20 PM UTC

minimaxir wrote: post #11

petetnt wrote: post #6

Earlier quoted context omitted.

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.

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

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.

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

#27

Post by encoderer » Sat, Apr 09, 2016, 11:59 PM UTC

bpicolo wrote: post #25

encoderer wrote: post #20

Earlier quoted context omitted.

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

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

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.

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

#28

Post by wing328hk » Sun, Apr 10, 2016, 4:19 AM 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…

Have you tried using Swagger-Codegen (https://github.com/swagger-api/swagger-codegen) to generate API clients, documentation (markdown) and test spec?

Disclosure: I'm a top contributor to Swagger-Codegen

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

#29

Post by stuartaxelowen » Sun, Apr 10, 2016, 3:31 PM UTC

amyjess wrote: post #22

stuartaxelowen wrote: post #3

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

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.

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

#30

Post by dmzza » Mon, Apr 11, 2016, 11:06 PM UTC

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.