I often hear clients and users request applications list of features and among their question appears: Do you guys provide a web service or RESTful API ?

Although the API approach has opened a new era of interoperability between systems and solutions, has greatly reduced the connectivity effort and simplified life to many of us.  However, there are as well numerous drawbacks and disadvantages. Occasionally, companies tend to neglect the growing significant costs incurred related to the development, the maintenance, the alignment with the product capabilities and the documentation that must be maintained up to date. Ask the experts of the cost accounting, they will be happy to make an exposé regarding the direct and indirect costs and their stake in a company.

Moreover, the APIs security concerns may add another surface of exposure and introduce new attack vector.  Indeed, OWASP had released a nice cheatsheet in order to sanitize RESTful APIs.  Browse it and you will see the issues I’m talking about.

There is one concern that worries me the most. It is about the API availability. Let’s assume your product is becoming increasingly popular and therefore more of your customers depend on it. Any outage or disruption to the API access can adversely affect your business. In addition, providing an API is also taking the risk to ensure its continuity among your users. You must then act as a clever strategist to announce new changes or a withdrawal.

Nevertheless, let’s not be pessimistic and avoid drawing a gloomy picture of the web API usage. All inconveniences which I have just mentioned are surmountable. That said, it may take a considerable effort, a good development team and excellent marketers to make the users swallow the bitter pill.

During the month of August 2016, vFeed IO has launched the distribution of its vulnerability and threat intelligence solution as a SQLite database. It is very easy to handle and above all downloadable. Our choice was reinforced to overcome precisely the annoyances I mentioned above. Therefore with a direct access to the database, our customers and users have the ultimate choice to build their own ecosystem. They may expand or develop their own tools to benefit from the solution added-value. And as mentioned earlier, it is a SQLite database. So it does not require extraordinary expertise to handle.

Now when it comes to the service outage, vFeed IO fixed the issue. I think you got it. The database is provided locally and consequently can be embedded within any solution.  That’s our strategy since the beginning that none of our competitors currently does . Others prefer to provide paid and restricted APIs. We just do things differently.

Recently, I had a chat with a new customer who found the idea of a local database extremely beneficial for him. In fact, it should be embedded with his new vulnerability management product boxes. My client does not want to take the risk, under any circumstances,  to communicate his boxes with external third party APIs.

However the hacking world is just fascinating and allows precisely to bypass the restrictions. Because we do hate restrictions. So there is for sure a nice way to create a web-based API for vFeed solution. In a recent update of our python wrapper, we added (thanks to the contribution of our users) the support to MongoDB. I think you understand where I am coming. I will detail in a further blogpost a nice way to create a RESTful API  using Flask and pymongo (the python driver for MongoDB).