56
votes
Are there any plans to publish an official API?
I understand there are no plans to develop an official app, which is understandable to me as that would require a lot of time and resources for a project like this.
But it's clear that there are lots of devs eager to chime in and create an app by themselves, just like they did for Reddit. There's even one iOS app already in progress, although it relies on HTML parsing to retrieve the data obviously.
So is there any official stance on this? Why not publish the API and let the community do its magic? Any thoughts?
I would also contend that alternate methods to access the site (honestly even in the form of mobile apps) will remove some of the concious site design decisions that encourage positive behavior.
One simple example is putting the 'Post comment' button at the bottom of the page. Its an intentional decision to nudge people to reading all comments first instead of just slapping down another. Once you have third party apps, that kind of design decision has less impact.
I'm not saying alternate methods should be banned, but care should be taken to not violate the spirit of the design.
You bring up a good point. Although I would argue that, if the site eventually gains enough popularity, that will happen anyway, as people will simply use apps that rely on HTML parsing.
I think creating an official API together with a set of guidelines may be a better way of controlling that, as you will encourage development towards good apps rather than the ones who rely on workarounds.
In fact, if the owner really wants to keep a tighter control over those aspects, I think it wouldn't be out of the question to have apps require official approval from Tildes.
For instance, API keys could, by default, have low limits in terms of calls per minute. Those limits would be suitable for development, but would make it impossible to release a mass market app. Devs would have to share a pre-release version of the app with Tildes, and only if the app is considered to respect Tildes' philosophy, they would get approval and the limits for their API key would be raised.
There are probably lots of options in-between the "all or nothing" approach we normally think of.
I would recommend any API is basically no different in volume to the user using the web site. Throttle it and tie it to a user account. By throttle I mean, don't allow 1000 calls a second etc, more like 1 every 5 seconds or something.
In a way, apps scraping the html plus built in limiters would be enough for any Dev to write an app around it, or have an option in the URL to show as XML/JSON and not HTML to make parsing easier.
The website could change its design and internal workings anytime though. It's usually not a good long-term plan to design apps relying on HTML parsing, especially with such a nascent website that's bound to change so much.
An API is a stable and efficient interface for devs to plug into.
This, 100%. Building on top of HTML scraping is a great source of anxiety 😄
I agree. The URL modifier to present the data in standard XML/JSON format would be easier to do and work for Devs too. Either way, I'd still throttle it.
In a similar train of thought... what benefit does an app give, is that something thats actually *good* for users or the site, and why do some people always want an app?
Tildes works very well in (my) mobile browser and the only things an app would give are things that promote addiction. Other big sites push their apps hard and gimp their mobile webpages to try to funnel you into an app that can be more addictive, scrape more data about you, and serve you more adds.
I can think of lots of things:
The website is OK, but the level of polish and smoothness that could be achieved through an app is unmatched.
A proper API and apps give folks the freedom to try different UIs. I'm quite happy with the current UI but if there were an app (especially one by RIF developer talklittle) I'd give it a shot.
Part of the reason there were so many Reddit apps (especially on Android) is that they all provided a slightly different view of the same information and I think that's great.
Think about the eternal "fight" that is Vim vs Emacs. They both edit text. Why do we need both? User preference.
As an age-old Redditor, I must point out that nothing's stopping someone from creating a "Tildes Enhancement Suite" add-on. (You know, as in Reddit Enhancement Suite.) If Tilde had a set of application design rules, and adhering to them would be a requirement for having API access, the first course of action for someone in dislike of Tildes' UI wouldn't be a complete wild-west no-rules Tildes-RES, but perhaps an app that has to adhere to at least some rules.
I mean, the point absolutely resonates, and I understand where that's coming from. But I'm not sure if "one size fits all" is the correct approach for the development of a social media service. Especially if "one size fits all" is the literal case. As others have mentioned, having a touch screen device and using Tilde is not really accessible, and the small touchboxes cause a lot of mispresses. And scrolling down to the bottom of the page on some mobile browsers is not a great experience. And not to mention people with certain disabilities, for whom the mobile website might be a slight barrier to entry. And as I mentioned, having an API doesn't mean giving complete wild-west freedom to the developers.
And as a final note, I'd also like to point out HackerNews, which is quite nice a place to discuss. I don't feel like their open-access API has really destroyed their culture or condoned some kind of toxic behavior.
It's accepted in the issue tracker but creating an API is arguably as much work as the interface you're looking at right now. You have to decide on all the same intimate details like authentication, authorization, formatting, privacy, security, etc. etc. That takes a lot of work.
Well, not saying creating an official API isn't work... in fact we develop APIs for a living at work :-)
But if Tildes were to create an official app, they'd need to develop both the API and the app itself. And unlike the API, an app requires lots of ongoing work, maintenance and bug-fixing. APIs are typically a one-time effort, after which they rarely require much work if no new features are added to the site.
The owners will know better of course. But I think it's always a worthwhile effort to create an API that others can plug into. You may get lots of cool integrations developed by the community eventually, and not just in the form of mobile apps but also in terms of automations and enhancements to the site itself.
And I haven't looked into the source code, so apologies if I'm saying something stupid. But I also assume there's already some kind of API in place, even if not officially documented, that the web client is using to access the backend. So it's usually good for the long-term life and maintenance of the site to standardise and publish that API so there's a clearer separation and a robust authentication system in place.
It's unlikely that there will be an official app any time soon since "The site is the main mobile interface, not an app". Most of the API that currently exists returns HTML for use with Intercooler, there are maybe 5 endpoints that return JSON if I recall correctly, so yeah... There isn't much to begin with. :P
Edit: I checked, there are 3 JSON endpoints and currently they are disabled.
Thanks! That's... interesting :D
Oh well, I guess we'll have to wait and see.
That is only true if the APIs are not just for third parties but also used internally. Otherwise anytime there are changes, even if they aren't new features, simple bug or security fixes, the two will diverge and the API will start breaking requiring maintenance.
Ideally that will have been taken into consideration during the initial design. Trying to retrofit can become an unbelievable nightmare. To the extent that sometimes it is easier just to start over with that in mind.
It causes a classic case of code rot.
The Reddit is Fun dev is working on an app, presumably for Android, but iirc in his thread about it he said it will have to work fundamentally different than the reddit one did.
Yes, it will basically have to scrape the site. So when you browse to a post in the app, it will load the full html/site, get the relevant information, and show it to you in the apps interface.
The work aside, this method is more expensive for Tildes than having an API, because it costs more server resources.
I don't see how an API would be a marked improvement over HTML parsing. Most websites that provide an API have their frontend in a constant state of flux, Tildes is very much the opposite.
With an API, Tildes only has to return a small amount of text instead of the full HTML representation for the same data. This is a huge savings for Tildes in resources required to serve the requests.
I have doubts that the savings from excluding the html exceeds the ability for html to be cached.
I don't think the HTML for Tildes is cached anyhow, as it'd cause loads of problems in being able to see new comments as they're posted. Taking a guess by the technology page on the blog, the pages are probably dynamically generated each time they're loading (might be cached for a very short amount of time). Not to mention that API GET requests for posts could be cached as well, not that there's usually a point considering they'd need to be refreshed pretty often.
Returning all the HTML required to render a page (which is a lot) is a waste of resources when all the client needs is the data itself in some readable way (usually JSON). It saves bandwidth for the site, and also speeds up clients by a significant amount. HTML parsing takes a lot longer than you'd think, and is a waste of both time and resources for the end user. I did a quick test, and simply parsing the comment data for this topic (which doesn't have many comments) takes about 2x longer than just getting the HTML page itself (getting a JSON endpoint would be even quicker), and this likely would not be a linear scale as the number of comments increases.
API calls are orders of magnitude more efficient than parsing HTML.
I don't have any interest in making an app, but I would love to be able to conveniently archive the data that I submit to the site. The easiest way to do this is an unauthenticated JSON API call that one could pipe into a different format, such as SQLite (a la hacker-news-to-sqlite)