3 ms·
Interesting service. The reporting and notification features are nice. Several things make me hesitant. And may not be enough to justify these features (at lea
by leepowers 13y ago
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 13y ago1) 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.