Opening the Instapaper API | Hacker News Reader

Opening the Instapaper API

blog.instapaper.com

84 pointsdsaw30 comments

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 to see related articles or what other people think besides my texts.

Instapaper comes as close to reading a ebook/book as it could get. At least for me.

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

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

Too late. I was a long time, paying customer but moved to Pocket.

On Android especially, the Instapaper app is way behind the Pocket one.

Pocket mostly applies successfully the latest Android design principles. It is not perfect, but it is a solid implementation.

Instapaper looks like it has been written by somebody discovering the support lib along the way. Bad drawer implementation, no attention to detail. It does not even look like the dev is using its own app, because there are some seriously low hanging fruit that should be easy to solve (for example I can't click on the drawer icon, only on the title for some reason).

It's hard to justify a subscription with such a weak effort and it is probably a vicious circle where the dev doesn't have a reason to improve his app either.

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.

In what circumstances does a HTTP server/client return to a partially complete response?

I think we've encountered another situation where developers who don't fully understand HTTP best practices and standards, are asked to adapt their internal API services to work on the web :(

The xAuth authentication method is suspect as well:

    xAuth provides a way for desktop and mobile
    applications to exchange a username and password for
    an OAuth access token. Once the access token is
    retrieved, xAuth-enabled developers should dispose of
    the login and password corresponding to the user.

https://dev.twitter.com/oauth/xauth

Asking users to trust third parties with the access details to your application? Sure they "review" the API token requests but who knows what that means.

Reading the page there seems to be a lot of talk about "keeping it simple" as if using the HTTP protocol is hard and confusing for developers. This is a bad sign, if they don't understand or care to understand something simple what are their security practices like?

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

Nice move, but I already moved to Pocket.

Interesting. I did the opposite a couple of months ago.

I am looking for something to replace pocket now that the old extension is dead and the new sucks. The service is still great on the phone but the firefox extension is crap:

- slow

- no red visual icon to signal the page is already stored

- no access to pages from firefox (bookmark not working for french locale or sthg)

- and the `new' button is just an add button that you have to stare at for 5 seconds because it will lose the focus and cancel the submission if you move to another tab.

Wallabag isn't quite ready yet :(.

I still love the UI of instapaper a lot more than the one pocket has on their iOS version.

The main reason I switched to pocket was that Instapaper doesn't seem to have support for PDFs.

I don't need any of the "position syncing" and other stuff. I just want to be able to download the PDF and view it offline in the same app that helps me do this to blogposts.

One gripe I have with Instapaper is how it formats code blocks. It doesn't look right at all (at least on the iPad version).

And they remove some images, so Wikipedia articles about math (with symbols as images) don't make sense. Diagrams and illustrations are often silently gone.

I keep reporting "some text/images missing", but overall I lost faith that I can read articles on Instapaper without missing anything.

It was the long-standing failure to handle code blocks and pull in images that moved me from Instapaper to Pocket. Have not looked back and finally got around to just nuking the instapaper app on my phone. After getting an early lead on the offline article niche Instapaper just squandered any goodwill by doing nothing to improve the product.

Instapaper is a lot stickier now. But the API appears to be write-only; neither there, nor anywhere else in the documentation, do I see any way to pull my data out of Instapaper if I should decide I no longer want to use it.

> But the API appears to be write-only

You can list your bookmarks (= saved articles), your folders and you can even fetch the processed-text HTML content for the bookmark, what else do you need?

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?

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.

This is perfect timing. I've had a back-burnered project waiting for a response from the API folks.

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.

Did you even read the article? The "full" API was always for premium users only.

Reply on news.ycombinator.com