4 ms·
> but having built APIs, ensuring that users use them correctly is hard Having used APIs, I don't really care if the organization who built it thinks I'm using
by pc86 3y ago
> but having built APIs, ensuring that users use them correctly is hard
Having used APIs, I don't really care if the organization who built it thinks I'm using it "incorrectly" as long as I'm getting the data out of it that I want. As long as I'm paying for it, I honestly don't think they have the right to say I'm doing it "wrong."
- Shrezzing 3y ago> I don't really care if the organization who built it thinks I'm using it "incorrectly" as long as I'm getting the data out of it that I want That's the way I think about it for stable APIs. But for API that are under constant development, using it "incorrectly" often results in your feature being inadvertently broken by developers who are unaware of your use case.
- danpalmer 3y agoI built a checkout API. Using it incorrectly could easily result in a user ordering items they didn't want to, paying an amount they didn't expect, selecting the wrong shipping, billing the wrong card, and so on. Building the API in such a way that it was hard for clients to get this wrong was a very key concern for us. Separately though, I gave a better motivating example in my other reply here. tldr: what you might be paying for may come with stipulations that are not clear in the data – such as how up to date data is when used. Those stipulations may come through many layers of data source, not necessarily from the layer you pay.