Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What’s your API’s “Time To 200”?

shkspr.mobi

Post reply on HN
Print view View original

51–60 of 90 posts

Re: What’s your API’s “Time To 200”?

#51

Post by 1123581321 »

gowld wrote: post #43
1123581321 wrote: post #18

Earlier quoted context omitted.

Agreed with the first two. I’m happy with a different pricing model so long as it’s financially viable at our usage tier and self-serve. On a project with a budget, or with funding, there isn’t a meaningful difference between a free trial, prorated per call, and paying for a month upfront.

Those are all "usage" based if you aren't nitpicking. The major alternative is app store (and some SDKs) style of revenue-bases pricing

Fair. Revenue-based is indeed frustrating if it inhibits self-serve; otherwise, I’ve no issue with it.

Re: What’s your API’s “Time To 200”?

#52

Post by KeepFlying »

dmlittle wrote: post #41
256DEV wrote: post #36

Earlier quoted context omitted.

My API currently does auth inline in the GET request URL in order to make this possible. An example request would be: GET https://v6.exchangerate-api.com/v6/YOUR-API-KEY/latest/USD I've had a fair number of users send me feedback saying this isn't the best practice, I should use tokens in HTTP auth headers or use various other auth schemes. But from my perspective, for an API that is offering really very simple funct…

The problem with having your API key in the URL is that they'll likely be logged all over the place when they're meant to be secret. You probably have the keys being leaked in logs, error reports, metrics, etc.

True and if this API handled user data or anything substantially private that would be a HUGE deal and super dangerous.

But it seems like in this case it's mostly a rate limiting and identification exercise and not a secure protection of user data so the impact of exposure is substantially lower. So it does seem reasonable here.

Though I hope that OP has documented all over the place "do as I say not as I do" so people don't copy this pattern.

Re: What’s your API’s “Time To 200”?

#53

Post by Silhouette »

b203 wrote: post #13

Is it really that important that the time to get to 200 should be small? I understand that it may be frustrating to get started, but assuming I am stuck to this API for a long time, I am lot more worried about stability, quality, performance and availability of the system than time to onboard.

I'm with you on those other aspects being very important, but I'm not sure they are more important in general. After all, relatively few APIs are truly essential, offering access to some exclusive facility that users of that API couldn't also find somewhere else and/or implement themselves. For everything else, unless you can hold enough of a potential user's initial interest for them to carry on trying things out, the other stuff doesn't matter.

Re: What’s your API’s “Time To 200”?

#54

Post by seanp2k2 »

Spivak wrote: post #24
jasonhansel wrote: post #20

Personally, few things annoy me more than APIs that can only be accessed via an SDK, and can't easily be called through e.g. cURL.

Looking at you literally all of AWS .

To be fair, it’s not like the GCP APIs are much easier to use. It’s probably the right thing for infra and payment services to have a higher bar for API security, plus they’re hugely complex and usually used as an SDK. That said, I haven’t been very impressed with the Google API dev experience. Example: I was just trying to post some timing data to Google Analytics via Go, and the documented example didn’t work in addition to being very hard to find. I eventually got lost in Firebase docs, which appeared to be wholly unrelated to what I was trying to do, had many additional separate APIs, required that I set up a new project in Firebase in addition to my GA “property”… On top of all of this, the GitHub auto-generated API examples were outdated (used a previous version that referenced deprecated docs) with no hints as to where to go from there.

In the end, I gave up, because I wasn’t willing to invest hours into learning all the idiosyncrasies. Ended up using Influxdata’s SaaS and got what I wanted going in about 15 minutes. To be fair, most of that time was also because their API docs didn’t actually work as posted and didn’t go through properly installing the client lib, which someone more experienced with Go probably would have gotten past more quickly.

Re: What’s your API’s “Time To 200”?

#56

Post by saagarjha »

nneonneo wrote: post #33

Most companies seem to maintain two APIs: a “private API” that they use to actually to deliver their website or service, and a second “developer API” for the exclusive use of third party services. If you’re just interested in putting together a quick hack or proof of concept, the private API often has a “time to 200” orders of magnitude faster than the public developer API: pop open the Network tab on your browser, p…

Many companies only have one API, and sadly it’s just the private one.

Re: What’s your API’s “Time To 200”?

#57

Post by mcint »

KeepFlying wrote: post #50
resonantjacket5 wrote: post #47

Earlier quoted context omitted.

You need to assign the API key to an email both for contacting and also a way to limit abuse.

But you could give a short lived highly limited API key out for testing to allow the potential user to test the API for their needs before bothering to make an account and providing their personal information.

Also, a way to register via that temporary api access

Re: What’s your API’s “Time To 200”?

#58

Post by stickfigure »

KeepFlying wrote: post #50
resonantjacket5 wrote: post #47

Earlier quoted context omitted.

You need to assign the API key to an email both for contacting and also a way to limit abuse.

But you could give a short lived highly limited API key out for testing to allow the potential user to test the API for their needs before bothering to make an account and providing their personal information.

How do you prevent someone from automating repeated "get new temp key"?

Re: What’s your API’s “Time To 200”?

#59

Post by 256DEV »

Kiro wrote: post #39
256DEV wrote: post #25

I've put a fair amount of work into getting this exact time as low as possible for my exchange rates API [1]. I've noticed slightly better conversion each time I've taken a major step out of the process. I've specifically eliminated some of the steps this article cites in its example of a tedious flow - for instance I changed user accounts to be confirmed by default and then only disable them retroactively if a user…

> I'm not sure how I could further improve the current flow Remove 1 and 2.

So I actually do have a version of my API that doesn't require any sign up at all for the users that prefer this!

You can see it here: https://www.exchangerate-api.com/docs/free

That said, as much as some users want an open endpoint with zero authentication there are many others who want an actual account, commercial support, high availability, more features etc. These users are also the ones that pay for development, infrastructure etc. so my service has to be 95% built around the flow that includes signup.

Re: What’s your API’s “Time To 200”?

#60

Post by stickfigure »

nneonneo wrote: post #33

Most companies seem to maintain two APIs: a “private API” that they use to actually to deliver their website or service, and a second “developer API” for the exclusive use of third party services. If you’re just interested in putting together a quick hack or proof of concept, the private API often has a “time to 200” orders of magnitude faster than the public developer API: pop open the Network tab on your browser, p…

I don't think any consumer of a public API would appreciate the churn of a private API. Either that or your web team is going to suffocate without the ability to make breaking changes.
Post reply on HN