I like public api's that provide access for non identified clients but they are throttled highly, versus clients who register to access a token.
It’s always worse when there isn’t an API.
That being said, the best APIs are the ones that have good understandable documentation. And I don’t mean some auto generated bullshit, but documentation that your developer can hand off to your data person and whatever project manager is ordering the information, and they’ll not only understand it, they can use it to tell your developer exactly which Y goes into X.
Beyond that you’ll want a decent test API, and you’ll want workable examples of how to make each call in JS/python/c#/java/php at the very least.
And you’ll probably still want the option for batch dumps via SFTP or whatever.
So no, I don’t think APIs are elitist, I just think most of the people who make them either suck or weren’t given enough resources to do a good job.
I disagree, Swagger is auto generated and I prefer to work with external APIs if they have Swagger documentation which allows me to easily test their API via web browser with two clicks, I don't have to open tools like Insomnia
Now, I'm not saying that it's an equal metaphor in any way, but worrying about API's not being accessible enough is only valid if the given consumer is having difficulties using/consuming the specified format. You can't write a spotify client with a csv as input, just like you can't read a book in a language you don't know.
I think this goes for computing as a whole. We on HN are probably in the crowd of people who feel completely in control of our machines and are fully capable of harnessing its compute power for nearly any communication or processing task we can imagine. More is better if you're an expert so a lot of our tools and services end up being very complicated and granular.
I think there are two dominant mindsets around how to respond to this problem: A) make services that abstract the technical complexity away from end-users or B) encourage users to become more technical or rely on a technical expert if necessary.
The third option is to simplify functionality down to a clear and simple set of easily understandable interfaces which are explicitly extensible where needed. If every industry had a commitment to doing that, we'd soon end up with a very obvious set of interoperable services with a common communication protocol and the possibility of vendor agnostic tools and services. In fact, I think this was the dream for the web at one point. Maybe we could revisit those ideas.
I don't mind an API that allows me to easily request the entire dataset I want to grab with a single unauthenticated call. When this is possible, it's easy to create a download link for less-technical users by hard-coding a query into an href tag. The issue is when an API forces me to make a large number of queries (often tens or hundreds of thousands) to construct a relatively small dataset. Combined with rate-limiting and authentication, the whole thing becomes a nightmare to work with.
Sure, the standard API interface is great if you want to programatically interact with an external database through a custom application. But that design does not lend itself well to accessing public data for the purpose of modelling and data analysis. But, it's not the API persay that's the issue. It's the way that APIs are designed.
With the explanation, if you have a product without an API, I guarantee you have a conceptual gap in the value you provide and why. If your product/data is valuable, users will put up with the most terrible UXs, but if you have the shiniest UX with gaps in the underlying useful data, you've basically got a videogame.
Then you need to look at what elitism is. It's not about requiring skills or physical competence to do something, as that would mean anyone who practised something would be a so-called elitist, which is absurd. Elitism is a way people without actual status affect or pretend to be as a way to convince others without status that they are elevated. Elitism is being a poseur. When you are a member of an actual elite, there is negative value in signalling it to an outsider, the only value is to signal your membership to other insiders. So someone who makes effort to signal their status to an outsider would therefore be an elitist.
Viewed that way, an API is not a signal, it is tool that literally refines the value of your data to that which is truly useful. My next product is starting as an API, and then I'm going to add UX skins to it because if it doesn't attract users, it won't be because of the trendy symbolism in the UX, it will be because it doesn't present the real meaningful data they need.
Please, make more APIs, as value for effort on all sides, it's the best possible solution.
You can download all the data, sliced and diced in various ways, via their download page: https://tatoeba.org/eng/downloads - and also via perma-urls. It's easy as pie. I've written a bunch of scripts to do it.
But then in their FAQ they have ( https://en.wiki.tatoeba.org/articles/show/faq#does-tatoeba-p...? )
> # Does Tatoeba provide an API?
> No, it does not (yet). We unfortunately do not have the proper infrastructure to host a public API[...].
And I'm like, "Nooo what you have is amazing. It's fine!". No need to be ashamed about having downloadable files!
But that's not all that APIs are, or are used for. For everything else, all of their complaints are still valid—bad user experience, authentication is usually a PITA, docs are often poor / non-existent / in a different language. But there isn't an easy solution for those like in the "download batch of data" case. So I think it would make more sense trying to find something that helps those situations, too. Definitely include a download link where possible, but don't stop there.
When building a backend, I lived through the age of custom exporters. It sucked. Having an API and the providing helper calls to do stuff like download the recent month in CSV is way better.
I like having an API that both the UI and users who want to directly integrate use as it’s just simpler.
The lesson may be that just having an API is not enough unless you have a big community or ecosystem building on it (eg, AWS).
a button you click to download a csv is an api, too!
Lots of things require expertise, and conflating prerequisites and elitism seems like an overall loss for effective communication.