What’s your API’s “Time To 200”? • Hacker News Board

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

#31

Post by 256DEV » Sat, May 22, 2021, 6:00 PM UTC

thecodemonkey wrote: post #8

I like to think that we’re doing okay with geocod.io, but I would seriously love some feedback. Should we automatically generate your first API key? Make docs more prominent? Anything else?

The Upload Spreadsheet button without any auth or form required is great. For any prospective users looking for this feature your time to being useful to them is approaching the theoretical limit. Only way faster would be to embed a small version of that page's form somewhere on your main landing page...

I really can't think of any other suggestions - your landing page is excellent, fast and I imagine highly converting with all the social proof. I also like the specific landing pages for each customer segment a lot, I really need to do that for my service.

Your site inspires me to work more on mine!

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

#32

Post by etaioinshrdlu » Sat, May 22, 2021, 6:03 PM UTC

If you have useful API's with a free tier, users will be constantly trying to steal them.

I've had to require email verification, non-cloud IP signup, block signup from IPs of already blocked users, in order to combat abuse. In all of these cases the user is just prompted to add a card to continue using.

I wish it weren't this way though, as it does harm the user's experience...

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

#33

Post by nneonneo » Sat, May 22, 2021, 6:05 PM UTC

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, perform an action, copy as cURL, run in terminal. Boom, 200. Twiddle a few parameters so it does what you want, and get on with building your demo or hack.

If that kind of learn-by-example speed was available for the developer API - or, better yet, companies actually used the same API for their service as a form of both dogfooding and to provide a great example, the API world would be a happier place.

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

#34

Post by dylan604 » Sat, May 22, 2021, 6:06 PM UTC

justin_oaks wrote: post #19

While "Time to 200" is an important metric, it's also important to have complete enough documentation for people to effectively use the API. There shouldn't be wholly undocumented corner cases. For example, I was using the Docker Engine API and I was trying to use the container GET archive call. The documentation says to use a file path, but it doesn't indicate the behavioral difference between using a file path endi…

>only covers happy paths or frequent uses,

Maybe, but there's no way a dev can possibly think of every single crazy thing an end user will try to do. There's a reason things are referred to as edge cases. You design a system to to work a specific way, and then document the workflow to make it work. Anything outside the documented procedure is eperimental. Sure, a dev can build as many bozo tests into the thing that they can think of, but users will always come up with something different.

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

#35

Post by dragonwriter » Sat, May 22, 2021, 6:06 PM UTC

aszen wrote: post #26

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.

famous example of this, are most of the aws api's that because of their signing features and hashes can really only be called sanely from an sdk. such a pain to debug, i'm not sure why they have such signing features. is it for security

> is it for security

Yes.

EDIT: specifically, it is do intercepting a request doesn’t allow you to issue new requests.

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

#36

Post by 256DEV » Sat, May 22, 2021, 6:08 PM UTC

treve wrote: post #28

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.

Or even better: allow me to paste the url in a browser and get a meaningful result.

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 functionality, using HTTPS & not handling user data etc. then this is quite OK - especially when you consider the benefits of how simple it is to get up and running.

I have quite a few university course conveners include my free API in their entry level CS classes because it's super fast & rewarding for students to go from finding my API to then having a JSON object in their code, no tokens required!

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

#37

Post by dylan604 » Sat, May 22, 2021, 6:11 PM UTC

treve wrote: post #28

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.

Or even better: allow me to paste the url in a browser and get a meaningful result.

How does that work for authenticated requests?

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

#38

Post by thecodemonkey » Sat, May 22, 2021, 6:12 PM UTC

etaioinshrdlu wrote: post #32

If you have useful API's with a free tier, users will be constantly trying to steal them. I've had to require email verification, non-cloud IP signup, block signup from IPs of already blocked users, in order to combat abuse. In all of these cases the user is just prompted to add a card to continue using. I wish it weren't this way though, as it does harm the user's experience...

We're doing something similar, requiring email verification in certain cases based on past traffic, ip address source, etc. Unfortunately, we had to straight up block known temporary email addresses because there was too much abuse.

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

#39

Post by Kiro » Sat, May 22, 2021, 6:24 PM UTC

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.

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

#40

Post by theginger » Sat, May 22, 2021, 6:27 PM UTC

I found some of the stats on here quite interesting https://status.zapier.com/#app-status Some of these apps may not be doing single api calls but it's a pretty big list gives a bit of a yard stick.