Thanks for the feedback JusticeJuice! We have definitely focused more on the API side of things more than the website at this stage but lots of website updates are in the works
Good idea, but it's difficult to justify building any commercial or mission critical applications that depends on it out of fear that it'll disappear the next day (bought out, given up, network issues, etc.). For that reason I can't see myself using it beyond a hobby app or one off script... even then I probably wouldn't use it.
You could say that about any PaaS, SaaS or API. But most of us have to depend on web APIs at some level. Most internet connected apps need some external services or APIs to keep them running properly. Also, because of the nature of some of the APIs, building and maintaining them in-house would not be viable or worth the effort therefor it saves you significant time and money by outsourcing these (that's why APIs for email and SMS etc are so popular)
One of the issues here is that there's no obvious alternative to switch to in most cases. Plus depending on a well-established company like Heroku (Salesforce) or Amazon is different then depending on something brand new.
Not to diminish the work put into this though. It looks great! :)
Well we all have to start somewhere! =) Plus we already have loads of happy customers that have been using some of our older APIs for more than a year now. Further to this, defensive programming goes a long way when working with APIs (both local and remote APIs). You should design your app in a way that it can continue to function even if an API malfunctions.
Damn... This is A W E S O M E! Congratz to the team! Feedback: It should be easier to change between apis. Doing this using <select> is terrible for the user. It really should be a sidebar or something like this.
Cheers luisrudge! I agree about the menu, we do have plans to change the layout to make it more like a traditional API docs page with the left hand contents/index panel type thing..
We have something like that already! If you signup for an account you can login and use our "API tools". No coding required, just a simple web based form you can enter data into and test out all the APIs =)
I would love if this would be something like a independend, modular micro-services architecture you can easily and selectively deploy within your own network. Docker might be a good way to manage it.
Thanks Fannon, we have been thinking about this quite a bit however the main issue is with data updates (which happen at a minimum on a daily basis). So if we did release something like this it would only be a suitable solution for online environments.
For the purpose of solving serious general programming problems like these on the server, most developers would probably rather want to use something like google app engine because it hosts code as well as static files for free, up to certain quota limits. That way, they can just play around with one of the zillions of open source python libraries, and then integrate it into their projects. Making third-party API calls is honestly something that developers want to avoid if at all possible.
While this can be true for some problems i'm not sure you have really thought about the details of the problems we solve other than a cursory glance.
Firstly, although python has loads of great open source libraries, you wont find any that can do all the things we can do.
Secondly, the volume of data that needs to be maintained and updated (on daily basis) is massive and way out of the scope of most projects (e.g. we maintain databases with more than 5 billion records which have to be updated daily).
Finally, although some of the APIs could run in a 100% local environment (we are looking into some ways to distribute this way) most either require a constant fresh data feed or need to connect to external systems e.g. to make and HLR query you must connect to the SS7 network which is not easily obtained and simply something most developers don't want to have to deal with.
Some of the APIs solve very complex problems indeed, which require constant maintenance and development on our part. However, this is the accumulation of about 15 years of software development across various projects and programming languages. The underlying API functions are already battle hardened so to speak
I would be using it to check if a user has created the correct DNS settings when they try to link their domain to a webhosting package of instance. Or wether someone has setup their domain correctly to receive emails.
We already have large commercial customers pushing more than a million data sets per hour for bulk processing.. its a fairly common use-case for us.
Also, you are greatly over simplifying these problems with a "I could build that" type statement. In my experience (more than 15 years as as professional software developer) this is something junior developers say all the time...
While i'm sure you might be able to roll some of these yourself in most cases its a waste of time and money and the constant maintenance of data is a real problem (as well as the quality of data). Some of our methods have taken a long time to perfect and test (years!) while other methods you would just not be able to implement yourself (e.g. HLR)
Lets examine one of the more simple APIs: IP Info (IP Geolocation). So you wan't to roll this yourself and run on your own gear. OK first, the data source. You need to find a quality source of IP geo data and load that into your database of choice. Great it works well, job done. Not quite, IP geo data is changing rapidly these days (mostly due to IPv4 exhaustion) so you have to keep downloading (and most likely paying for) database updates. The provider doesn't provide an automated way to do this, so you have to build that as well. They also seem to charge a lot of money for the "full" database. Later it turns out some of their data is highly inaccurate, so you have to find other suppliers, they use a totally different format so you have to re-implement that as well.. I think you can see where this is going..
That's just a trivial example. Most of our APIs are far more complex than IP info is and require much more work and maintenance to keep running.
Most of the APIs require data to be gathered, analysed and updated on a daily or weekly basis (e.g. BIN lookup, IP Info, Geocode, IP blocklist, User-agent Info, Phone validate). Some need to connect directly to other networks (e.g. Phone verify, SMS verify, HLR lookup, Host Reputation, Currency Convert). These would be either impossible or quite difficult to implement in a library / local only environment. Others can just be a pain to implement (depending on your setup). Additionally, you gain the advantage of automatically inheriting updates to our algorithms and data sources.
Ah, I didn't realize that these were updated, I thought it just used a regex to verify the email, phone number, filter bad words, etc.
A lot of these seem useful and having APIs that need to be updated is a good VP, however for things like HTML to PDF, there are libraries that already do this.
People will likely use the HTML -> PDF API, but in terms of the new APIs you are developing, I think you will attract more customers with things that cannot be implemented simply with a library and instead need to be managed by you.