News for hackers. Stuff that matters.
Re:Show HN: API Happiness is not a 'nice-to-have' by jrochkind1 on Wednesday April 02, 2014 @12:05PM (#7516490)
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?

Re:Show HN: API Happiness is not a 'nice-to-have' by levirosol on Wednesday April 02, 2014 @12:10PM (#7516536)
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.

Re:Show HN: API Happiness is not a 'nice-to-have' by Lambdanaut on Wednesday April 02, 2014 @12:55PM (#7516944)
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.

Re:Show HN: API Happiness is not a 'nice-to-have' by _mikz on Wednesday April 02, 2014 @02:04PM (#7517626)
We are planning on-premise version which should work for all API calls - https://news.ycombinator.com/item?id=7517338
Re:Show HN: API Happiness is not a 'nice-to-have' by _mikz on Wednesday April 02, 2014 @01:26PM (#7517227)
You can write Lua middleware to do the Auth if you want. The traffic monitor website is protected by us, but the actual proxy is not authenticated as it could interfere with API you are using.
Re:Show HN: API Happiness is not a 'nice-to-have' by jrochkind1 on Wednesday April 02, 2014 @01:44PM (#7517434)
Huh, so using this service will turn any authenticated API into an open api, usable by anyone that knows the URL?

That seems... unsuitable for most non-public apis.

Re:Show HN: API Happiness is not a 'nice-to-have' by _mikz on Wednesday April 02, 2014 @02:03PM (#7517616)
It is a proxy, so if you don't explicitly add keys with a middleware the API will still need the auth.

But you can do key mapping: if you pass your key it will transform it to the real one and if not, then it will just return 403.

Re:Show HN: API Happiness is not a 'nice-to-have' by mbesto on Wednesday April 02, 2014 @01:47PM (#7517463)
Isn't this effectively what Mashape does?

http://mashape.com/

Re:Show HN: API Happiness is not a 'nice-to-have' by njyx on Wednesday April 02, 2014 @02:45PM (#7517973)
No - Mashape is a marketplace to signup for APIs. You can call APIs through the mashape but you don't get the middleware control layer or detailed alerts/analytics.
Re:Show HN: API Happiness is not a 'nice-to-have' by _mikz on Wednesday April 02, 2014 @12:11PM (#7516541)
We had other landing page prepared. If you refresh now, you should see it.
Re:Show HN: API Happiness is not a 'nice-to-have' by jrochkind1 on Wednesday April 02, 2014 @12:20PM (#7516620)
Thanks, that is more clear, to me anyway!

Although, for the technical audience (and isn't a technical audience the only audience for this product?), actually using the word 'proxy' somewhere might help make it even more clear. Although I could be wrong, maybe I'm not representative, but it would make it clearer for me anyway.

Re:Show HN: API Happiness is not a 'nice-to-have' by _mikz on Wednesday April 02, 2014 @12:27PM (#7516691)
Agree. Will try to do that. Thanks!
Re:Show HN: API Happiness is not a 'nice-to-have' by leepowers on Wednesday April 02, 2014 @03:29PM (#7518305)
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 ("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!

Re:Show HN: API Happiness is not a 'nice-to-have' by _mikz on Wednesday April 02, 2014 @04:22PM (#7518700)
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.

Re:Show HN: API Happiness is not a 'nice-to-have' by coderaptor on Wednesday April 02, 2014 @11:58AM (#7516424)
I've been thinking of implementing a similar dashboard with 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?

Re:Show HN: API Happiness is not a 'nice-to-have' by njyx on Wednesday April 02, 2014 @01:35PM (#7517338)
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.
Re:Show HN: API Happiness is not a 'nice-to-have' by elwell on Wednesday April 02, 2014 @01:40PM (#7517386)
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?
Re:Show HN: API Happiness is not a 'nice-to-have' by njyx on Wednesday April 02, 2014 @02:50PM (#7518009)
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.
Re:Show HN: API Happiness is not a 'nice-to-have' by bennyg on Wednesday April 02, 2014 @11:45AM (#7516313)
"Analyze"
Re:Show HN: API Happiness is not a 'nice-to-have' by JohnBooty on Wednesday April 02, 2014 @11:51AM (#7516369)
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")

Re:Show HN: API Happiness is not a 'nice-to-have' by njyx on Wednesday April 02, 2014 @11:53AM (#7516384)
Yep - fixing that.
Re:Show HN: API Happiness is not a 'nice-to-have' by vanessarp on Wednesday April 02, 2014 @12:03PM (#7516478)
Fixed! Thanks for noticing!
Re:Show HN: API Happiness is not a 'nice-to-have' by lleims on Wednesday April 02, 2014 @11:53AM (#7516382)
I think it's already been fixed.
Re:Show HN: API Happiness is not a 'nice-to-have' by henridf on Wednesday April 02, 2014 @01:48PM (#7517468)
The "insert middleware in API traffic handling" is reminiscent of F5 iRules in a different context (and epoch!).
Re:Show HN: API Happiness is not a 'nice-to-have' by plunchete on Wednesday April 02, 2014 @12:02PM (#7516460)
I love the concept of the middleware to modify the requests. When are you guys going to start sending the invites?
Re:Show HN: API Happiness is not a 'nice-to-have' by _mikz on Wednesday April 02, 2014 @12:34PM (#7516753)
Right now. It shouldn't take more than a day unless we encounter some errors.
Re:Show HN: API Happiness is not a 'nice-to-have' by plunchete on Wednesday April 02, 2014 @12:49PM (#7516882)
Thanks!
Re:Show HN: API Happiness is not a 'nice-to-have' by johns on Wednesday April 02, 2014 @12:59PM (#7516979)
What kinds of things would you use it for?
Re:Show HN: API Happiness is not a 'nice-to-have' by plunchete on Wednesday April 02, 2014 @01:32PM (#7517300)
Different API keys in there instead of my app, alerts when the API is down, headers, etc. I think it's kind of nice that I don't have to code them or that I just have configure my app to use 3 different API tools end-points for dev, qa, prod. But I really think that the best usage for them is monitoring
Re:Show HN: API Happiness is not a 'nice-to-have' by tobych on Wednesday April 02, 2014 @02:41PM (#7517951)
I'd suggest you replace the music with a voice-over that explains what's going on.
Re:Show HN: API Happiness is not a 'nice-to-have' by _mikz on Wednesday April 02, 2014 @04:23PM (#7518710)
We will try it when doing more videos! Thanks.
Re:Show HN: API Happiness is not a 'nice-to-have' by ismaelc on Wednesday April 02, 2014 @12:35PM (#7516765)
Looks like Runscope
Re:Show HN: API Happiness is not a 'nice-to-have' by njyx on Wednesday April 02, 2014 @02:49PM (#7518000)
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!

Re:Show HN: API Happiness is not a 'nice-to-have' by johns on Wednesday April 02, 2014 @04:39PM (#7518832)
For clarity, we (I'm the CEO of Runscope) offer two products: Runscope Traffic Inspector for logging/monitoring traffic to any API and Runscope Radar for ongoing automated testing. I don't mean to hijack the thread, just want people to know we do a bit more than just testing. Congrats on the launch!
Re:Show HN: API Happiness is not a 'nice-to-have' by ismaelc on Wednesday April 02, 2014 @03:45PM (#7518414)
Does this mean I can program throttling? That sounds cool if it does that.
Re:Show HN: API Happiness is not a 'nice-to-have' by _mikz on Wednesday April 02, 2014 @04:26PM (#7518735)
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 :)
Re:Show HN: API Happiness is not a 'nice-to-have' by nubs on Wednesday April 02, 2014 @12:15PM (#7516577)
So how does this compare to something like apigee?
Re:Show HN: API Happiness is not a 'nice-to-have' by _mikz on Wednesday April 02, 2014 @12:36PM (#7516768)
It proxies outgoing calls so it is for API consumers. Apigee is for API providers.