

Show HN: API Happiness is not a 'nice-to-have' - _mikz
https://www.apitools.com/

======
jrochkind1
I'm having trouble figuring out what this actually does from the web page,
although it sounds intriguing.

Although if other HN users aren't having that trouble, maybe it's me, not you.

Do you essentially use this as a proxy, where your apps contact it, and it
contacts the apis, so it can keep stats on your api use? That's what the three
phrases on the home page sort of imply.

But then when I watch the video... it all goes by so fast, but it's giving me
the idea that I had it wrong, and it's doing something else (CORS? What would
CORS have to do with what I thought it was doing?)

Is it too much to ask for a couple sentences/paragraphs explaining what it
does, instead of just a couple words and a video?

~~~
levirosol
Reading the docs, I understand it to be a proxy for your APIs. You setup a
service for api.somedomain.com, and then you change that URL in your app to be
someprefix.apitools.com.

Being a developer who heavily utilizes internal and external APIs, I like the
idea of a tool like this, however, I'm really hesitant to run all calls
through a single 3rd party. Especially one this green.

The next question I have is, what about auth? It seems like it could get
really messy / insecure using something like this.

Seems like a great project to open source and to run on your own hardware.

~~~
Lambdanaut
This is the understanding I got as well.

Another concern of mine is that now you're running all calls to an API through
yet another service, increasing latency on potentially frequently-called
methods.

It's certainly not for all API calls.

~~~
_mikz
We are planning on-premise version which should work for all API calls -
[https://news.ycombinator.com/item?id=7517338](https://news.ycombinator.com/item?id=7517338)

------
leepowers
Interesting service. The reporting and notification features are nice.

Several things make me hesitant. And may not be enough to justify these
features (at least for me).

Current blockers:

1) Single point of failure. Let's say I use the Reddit API and the Facebook
API. If one goes down I still have the other. If apitools goes down I lose
both. And what's more likely? For either Facebook or Reddit to go down - or
for apitools to go down?

2) API abuse. If an apitools user abuses an API, the apitools server will get
blocked. And so other innocent users will also get blocked. Is there any plan
to mitigate abuse? If that plan fails, how quickly can new IPs be allocated to
get around any IP bans?

3) Security. PII is sent to APIs. How do I know this information isn't logged
or otherwise accessible to other apitools users? The heart of the issue is
trusting strangers running a new proxy service with sensitive info.

4) Security #2. SSL support? Looking at the following screen shot it appears
that currently I'd be transferring PII and API keys in plaintext:
[http://docs.apitools.com/images/overview.png](http://docs.apitools.com/images/overview.png)
("Apitools URL")

5) Price. How much will the service cost? If there's a free level, what are
the limits?

6) Latency. Essentially doubles the number of API requests. Wouldn't this make
my API requests twice as slow? More importantly, if apitools is under load and
experiences longer response times, my site is going to run slower.

Even with these objections it looks like a great product. And these blockers
may very well end up being irrelevant for most potential users. Best of luck!

~~~
_mikz
1) we will release on premise version to address that (yes, you can deploy
more machines to do HA and load balancing)

2) AWS allows us to get new IP addresses quickly and APIs will ban rather the
auth key than the IP address no? There are huge networks behind NAT like
mobile and companies so providers has to count with that.

3) We enforce single point of entry to the Traffic Monitor through the
generated unique URL and key we generated for you. The monitors are jailed on
several levels, so they can't access outside resources.

4) We are having optional SSL now but enforcing it in next days.

5) We don't want to enforce any limits other than abusing the service. Do you
have any numbers to share? We were thinking about 10req/s should be enough for
everyone.

6) It should not double the response time because we are not slow as the API
you are asking. Of course it depends where is your client and how many request
we will be having, but we have plan for spreading the load and moving monitors
around. Also 1)(on premise) is in the works which should have almost 0
latency.

Thanks! If you are interested write us a mail and we can chat how to improve
things.

------
coderaptor
I've been thinking of implementing a similar dashboard with
[https://github.com/jkassemi/stubby](https://github.com/jkassemi/stubby).

I like the concept of this long term allowing me to specify a single url and
toggle the environment of the API I'm hitting from a remote, secure web
interface. What sort of uptime and scaling guarantees do you intend to
provide?

~~~
njyx
There will be an on-prem version of this too pretty soon. On the hosted we're
benchmarking, but it'll depend where you're hosted. If you're Amazon EC2 you
should see very low latencies.

------
elwell
So if someone abuses the proxy and gets ip blocked the entire service fails
for that api for all users, or am I missing something?

~~~
njyx
We monitor traffic in and out closely and we have multiple IPs out of the
back. However, if you're doing heavy production usage there is an on premise
version coming.

------
bennyg
"Analyze"

~~~
JohnBooty
Yes. The owner of this product should probably fix that quickly - "Analize"
isn't a word, but if it was, it would be humorously scatological. Or
scatologically humorous. _Something._

(For the benefit of anybody whose first language is not English, "Anal" =
"having to do with the anus")

~~~
njyx
Yep - fixing that.

~~~
vanessarp
Fixed! Thanks for noticing!

------
henridf
The "insert middleware in API traffic handling" is reminiscent of F5 iRules in
a different context (and epoch!).

------
plunchete
I love the concept of the middleware to modify the requests. When are you guys
going to start sending the invites?

~~~
_mikz
Right now. It shouldn't take more than a day unless we encounter some errors.

~~~
plunchete
Thanks!

------
tobych
I'd suggest you replace the music with a voice-over that explains what's going
on.

~~~
_mikz
We will try it when doing more videos! Thanks.

------
ismaelc
Looks like Runscope

~~~
njyx
Runscope is a bit different in that it focuses more on API Testing, APItools
focused on monitoring the live traffic to the APIs and controlling it with
programmable middleware.

There's a bit overlap but it's definitely worth checking out both!

~~~
ismaelc
Does this mean I can program throttling? That sounds cool if it does that.

~~~
_mikz
Yes. Also returning cached responses if you want. It is full blown programming
language inside. Parse XML? Yes. Transform JSON? Yes :) Implement OAuth? If
you dare :)

------
nubs
So how does this compare to something like apigee?

~~~
_mikz
It proxies outgoing calls so it is for API consumers. Apigee is for API
providers.

