Live data from Hacker News

Opening the Instapaper API

blog.instapaper.com

21–30 of 32 posts

Re: Opening the Instapaper API

#21
post #13

Get users -> deactivate 3rd party access to API -> lose users -> reactivate 3rd party access The circle of life. Wonderful.

There was never any "official" 3rd party access to the API other than an "add article" action. And when the API was made available, it was only to subscribers since the main revenue stream was sales of the official app. Since the official app is now free, that revenue stream doesn't need to be protected, and thus the API is now available to everyone.

Re: Opening the Instapaper API

#23

All the methods that need to append `add`, `delete`, `update` to the URI. Why aren't you just using HTTP methods for this? Why do I have to POST everything? Do you know what POST is supposed to be used for?

> Why do I have to POST everything?

Because it's an RPC-based API?

Re: Opening the Instapaper API

#24
post #12

This surprises me a bit: "All requests should be made via the POST method, and all parameters should be passed in the POST request-body and not in the query-string." So even typical GET are sent as POST (/api/1/bookmarks/list) Is there any reason to do that?

> Is there any reason to do that?

That it's RPC over HTTP, POSTing everything is the normal (and, really, proper) way to do RPC over HTTP.

Re: Opening the Instapaper API

#25

How do you find an RSS feed of all archived Instapaper articles? This is needed to connect Pinboard with Instapaper.

It's provided as a `link rel="alternate" type="application/rss+xml"` on the /archive page (or any other folder). Sadly less and less browsers display these (or even indicate there's one) so you'll have to dive into the JS console or page source to extract the URL. I don't think there's an easier way to get at the RSS feeds.

Re: Opening the Instapaper API

#26

How do you find an RSS feed of all archived Instapaper articles? This is needed to connect Pinboard with Instapaper.

It's provided as a `link rel="alternate" type="application/rss+xml"` on the /archive page (or any other folder). Sadly less and less browsers display these (or even indicate there's one) so you'll have to dive into the JS console or page source to extract the URL. I don't think there's an easier way to get at the RSS feeds.

Thanks for that tip on RSS feeds for folders. Looks like the feed of new items is also accessible via Settings > Download > RSS.

Re: Opening the Instapaper API

#27
post #7

I love this! I feared that Instapaper development would stagnate after Marco sold it. Even though he said that they will develop a lot of new features, you know how it often times is when companies/apps get bought. But i'm happy to see quite the contrary! What i love about Instapaper is the fact, that it doesn't fuck around. It tries to be one thing and one great thing only. I don't want to see tweets, i don't want t…

Instapaper actually stagnated before Macro sold it (which he will admit to). Betaworks has been very active on it since day one.

Re: Opening the Instapaper API

#28
post #7

I love this! I feared that Instapaper development would stagnate after Marco sold it. Even though he said that they will develop a lot of new features, you know how it often times is when companies/apps get bought. But i'm happy to see quite the contrary! What i love about Instapaper is the fact, that it doesn't fuck around. It tries to be one thing and one great thing only. I don't want to see tweets, i don't want t…

> I feared that Instapaper development would stagnate after Marco sold it.

Unfortunately "not stagnating" and "developing a lot of new features" these days usually means you will in fact soon start seeing tweets, related articles and what other people think besides your texts.

Which is a shame, because I too love the minimalistic approach of Instapaper.

Re: Opening the Instapaper API

#30
post #14
post #12

This surprises me a bit: "All requests should be made via the POST method, and all parameters should be passed in the POST request-body and not in the query-string." So even typical GET are sent as POST (/api/1/bookmarks/list) Is there any reason to do that?

It gets even better: > If the response is not valid JSON, it should be interpreted as an HTTP 503 "Service Temporarily Unavailable" error, and the request should be retried later. Why not just return 503?

Maybe it does, normally. But there's always an outside chance that everything's fine at the point you start writing a response, but goes pear-shaped before you finish. This wording just reinforces what's probably common sense, i.e. that there's no reason you'd see invalid JSON other than a hopefully-transient operational issue.
Post reply on HN