Jim The COO and Bret The Evil Database Manager Episode 1: Getting some REST

Jim The COO and Bret The Evil Database Manager Episode 1: Getting some REST

Jim decided that Bret must be evil. Pure, unadulterated, taking-candy-from-a-laughing-baby evil. How else could you explain it? Only a man of malicious intent would put Jim into this position.

He was sure that he had lapped the office at least one million times looking for the elusive database manager. His legs were tired and he was beginning to get looks from his fellow coworkers. He passed a customer service representative. Had he seen Bret? No. He passed the CFO. Had she seen Bret? No. He rounded a corner and passed the IT guy. Had he seen Bret? It’s very important and really can’t wait. No, sorry, but the IT guy would let Bret know that Jim was looking for him, if that was any help.

It wasn’t, but Jim said that would be great, thanks! and resumed his downward spiral around the office. Five minutes ago it had been 4:25 p.m. on an almost-over-Friday and Jim the COO had been looking forward to the weekend. He was going to go camping. Jim loved camping. It was restful and rejuvenating, which was just what he needed before the trade show on Monday. Sure, there was pressure. All of the big e-commerce partners were going to be there to witness the unveiling of a special API Jim’s company had been working on for months now. And sure, Bret the lazy, morally suspect, procrastinating database manager was the one heading that particular project. But, Jim had reminded himself at 4:27 p.m., Bret had been emailing updates (albeit vague ones) on the project for months now. Nothing to worry about, right?

Wrong. At 4:30 p.m., Jim was forwarded the following email from the CEO of the company:

Forwarded Email

The email had been sent with high urgency. The CEO had written only two words above the original text: “Address this.” Jim had been working at the company since its inception. That was long enough to know that, if he didn’t “address this,” he wouldn’t be working at the company for much longer.

Maybe he was being dramatic.

Immediately after receiving the email from the CEO, Jim walked to Bret’s office. The door was closed and the blinds were down, as usual. He knocked and there was no answer. Jim walked away feeling frustrated, too frustrated to wonder why Bret’s Lair was the only office that had blinds.

At 4:35 p.m., Jim called Bret. At 4:37 p.m., Jim had left a message on Bret’s office phone. At 4:45 p.m., Jim began to sweat profusely. Then, finally, at 4:52 p.m., Jim received the following email:

Auto Response Email

At 4:54 p.m., Jim decided that he wasn’t being dramatic and that Bret must be evil. He went back onto the floor and began making laps around the office. At 4:56 p.m., he ran into that IT guy, the one that would let Bret know that Jim was looking for him. Then, upon rounding another corner, Jim ran into Dave the developer. Dave was on Bret’s team. However, Bret was not fond of Dave, nor Dave of Bret (something about Dave insisting that Bret follow best practices and Bret insisting that Dave bring donuts more often). Jim was nigh hopeless at this point, but he figured he’d give it a shot. Had Dave the developer seen Bret?

No, he hadn’t. But he knew, instantly, what Jim’s problem was. He had been expecting Bret’s questionable progress on the project to end up ruining somebody’s day at some point. To Jim’s relief, Dave offered his insight. Maybe, maybe, Jim wouldn’t need to find Bret after all. Maybe he, and Dave the Divine Developer, could handle this themselves. Dave began to explain the goals of the project.

Truthfully, Jim didn’t understand all of the technical details. Dave boiled it down. Basically, the company was supposed to present a RESTful API for their relational databases that was easily navigable and allowed dynamic data manipulation. Because Bret had hamstrung the project, the company had nothing to present. However, Jim now had something to work with.

And, lo, Jim does what every person does when they absolutely need an answer and have no idea how to go about finding it. He searched the internet. His hopes weren’t high but, hey, he figured he’d give it a shot.

Google Search Result

He couldn’t believe his luck. This service, SlashDB, would provide all of the necessary functions of a RESTful API. On top of that, it had the potential to save the company an estimated $30,000 – $40,000 per year. It even had a search bar. The site said it could be set up within hours, which was shorter (by several orders of magnitude) than the time estimate that Bret provided in his email.

Jim was thrilled. He experimented with the demo and, to his delight, found that the service was intuitive and easy to use. Dave also explored the demo and explained that there were several other, more technical features that were particularly useful (the option to visit a destination page using multiple different representations, automatic reflections in the API if the database was changed, the solid security features, etc.). The best part was the setup. The site said that it was, essentially, automatic. Dave confirmed this to be true. Bret wouldn’t even have to participate.

On Monday, when Jim and Dave presented the SlashDB implementation to the CEO (so the CEO could present it to the partners), Bret happened to be in the office. He was furious. He couldn’t believe that Jim would just work around him like that, especially after all of the work that he had put in to the original project. When Dave heard this, he had to cough to stifle his laughter. Bret could tell he was defeated and excused himself from the office with his eyebrows, and his head, lowered. As he walked out, both Bret and Dave could have sworn that they heard phrases like “I can’t believe that traitor,” and “he’ll rue the day he crossed me” muttered under Bret’s breath. The CEO, however, was too delighted with Jim and Dave’s solution to notice. The trade show was in a couple of hours, and everyone (save Bret) was confident that SlashDB would leave the company’s e-commerce partners impressed.

Jim doubted that Bret would let this go. Even with this obstacle surmounted, Bret could provide all sorts of road blocks in the future. He swallowed and tried not to think about it. He and Dave had “addressed it,” at least for today. And, Jim thought, that wasn’t such a bad way to start the week, after all. Especially after a pleasant weekend of rest and relaxation in the woods.

Bret swears his revenge. Jim wonders why Bret would say such a strange thing at the office.

To Be Continued…

SlashDB ver. 0.8 Debuts on Microsoft Azure

SlashDB ver. 0.8 Debuts on Microsoft Azure

The latest version of SlashDB launches on Microsoft’s cloud — a direct result of a partnership agreement between VT Enterprise and Microsoft. Pricing starts at $0/hr.

SlashDB is an automatic REST API for databases. The product instantly enhances existing web-based systems with a flexible data API for reading and writing in JSON, XML and CSV formats. Using SlashDB, web businesses achieve the shortest time to market for their API initiatives in marketing, e-commerce or data monetization programs. Enterprise clients utilize SlashDB to enable traditional client/server systems to work with modern HTML5 and mobile front-ends.

Indisputable Return on Investment

Microsoft_Azure_CertifiedUp to 90% of API development time can be saved by deploying SlashDB software. With the instant availability and pay-as-you-go per-minute billing for SlashDB on Azure there is no delay to start an API project and no upfront costs for hardware, networking and software development.

SlashDB clients report $30-$40k in savings per annum per developer. Developers can often entirely avoid boiler-plate data access code in Java Enterprise Edition (JEE), Microsoft .NET, PHP, object relational mappers (ORM) or other code-heavy approaches. Repetitive work is avoided due to SlashDB’s unique ability to automatically emerge new API endpoints as new tables are added or changed in the database.

What’s New in Version 0.8


SlashDB version 0.8 is immediately available from Microsoft Azure Marketplace and for on-premises installation. Version 0.7 is also available on Amazon Web Services with the update coming soon.

UPDATE: AWS Marketplace has the latest version now too.

SlashDB Puts 2014 to REST

SlashDB Puts 2014 to REST

We are saying our goodbyes to 2014 with the final update to version 0.7 of SlashDB. Amazing new features await in 0.8, so stay tuned, but in the meantime, here’s…

What’s New

SlashDB ver. 0.7.39

Final revision of the 0.7 version contains over 20 improvements and fixes including:

  • Improved conformance to REST/HTTP standard by adding support for Accept header
  • Bundled support for IBM DB2
  • Improvements to database configuration GUI
  • Improved warning and error messages in admin’s GUI
  • Improved handling of date/time types for update
  • Fixed certain minor GUI issues (i.e. database dropdown, login box, sorting)
  • Fixed incorrect handling of boolean fields and empty values in CSV data upload
  • Fixed certain issues with XML representation of the NUMBER data type
  • Stronger user-resource authorization

R Stands for Representation

The “R” in REST stands for representation of a resource. While the vast majority of APIs can only output a JSON format, SlashDB from the very first version emphasized the need to provide alternative representations. We are pragmatic programmers, so the requested representation could be conveniently specified as a “file extension” in the URL:

The problem with this approach is that it commingles resource identification with representation. One could argue that the above are four distinct resources because each uniform resource locator (URL) is different.

The solution to this is already designed into the HTTP protocol as the “Accept” header. From this version onwards SlashDB fully supports it (but we will keep the old way forever). And so, the Playlist resource identifier becomes:

By default an HTML representation will be returned, so to select an alternative representation, send the desired content type with your request. Here’s how to do that with a popular command line tool curl:

curl -H "Accept: text/xml"
curl -H "Accept: application/json"
curl -H "Accept: text/csv"
curl -H "Accept: text/html"

So there you have it. Now you can pick your way: strictly REST/HTTP correct or convenient.

Happy New Year

Thank you for your support all year and have a happy and prosperous 2015!

How Bloomberg Uses REST APIs

How Bloomberg Uses REST APIs

Bloomberg Industry Leaderboard Uses REST API for Financial Data Visualization; Imagine What You Could be Doing with Your Data Assets

If you have visited Bloomberg’s website lately you may have noticed a new tool called Bloomberg Industry Leaderboard, which is a part of their Visual Data site. The Leaderboard presents fundamental data about 600 leading global corporations in a visually attractive manner. Visualization techniques such as tree map, colored grid and rankings are all dynamically configurable, and results are sorted on the fly.



While the concept of presenting fundamental metrics in similar ways is not new, and there are many websites with similar data and visualization, the technical details behind the site are worth examining a bit closer.

Traditionally, data-driven  web pages respond to users input (clicks) by requesting from the web server a fully prepared page, coded in HTML for the browser to render. This typically results with reloading of the entire page upon each interaction or (more recently) with replacing fragments of existing HTML with new ones. In contrast, Bloomberg’s site uses REST/HTTP API to get raw data, which the browser then combines with a shell HTML page using Javascript and Cascading Style Sheets.

For us what is even more interesting is that Bloomberg seems to follow a very similar approach to that of SlashDB. Here’s an example of companies broken down industry and ranked by operating margin and estimated net income growth: (HTML representation) (underlying data)

By comparison, SlashDB links (to an unrelated data set) look as follows: (HTML representation) (underlying data)

Imagine what you could do by layering SlashDB on top of your data. Use it internally for data federation, database search and self-service reporting, or deliver data to the web and mobile apps, or even offer your data assets for sale. Either way, the time to market is about an order of magnitude shorter than custom developed solutions, as our customers have attested. SlashDB is also more versatile as it allows for reading and writing of data and provides alternative data formats. It just as easily integrates with Excel, R, Matlab and enterprise systems as it does with the web.

As you may know, the idea for SlashDB was conceived out of the issues with access to market data in large investment banks. Had Bloomberg used SlashDB, they could have saved a ton of time and money.

Try /db Risk Free

If you would like to learn more about SlashDB or to discuss REST APIs in finance or in general, please contact us. You can also register here to try our product risk free.

20 Business Models for Web APIs and How to Be Ready

20 Business Models for Web APIs and How to Be Ready

Whether your are aiming for driving innovation, building partnerships or for an opportunity to expand your service or product, you need to know about business models that can be adopted to accomplish your goals with web APIs.

Our own clients typically begin with just one business reason for building an API, but they are ready for any change in business requirements with little additional effort. SlashDB provides unobstructed access to their data assets via an instant web API.

Enable web and mobile applications for reading and writing, improve data management internally or provide on-demand data feeds in standard formats.

One of the most interesting resources about the business of APIs is this presentation from the first API Strategy & Practice conference: “API Business Models” by John Musser, founder of ProgrammableWeb. Find out what API business models are used by Sprint, Expedia, Google, Netflix, Facebook, New York Times, Amazon, PayPal,, Intuit and other online business leaders.

Leaders From FullContact,, Urban Mapping and SlashDB Discuss the Future of Data

Leaders From FullContact,, Urban Mapping and SlashDB Discuss the Future of Data

Victor Olex represented the SlashDB team on a panel about the future of data at the API Strategy & Practice conference. See the video below for  an hour-long session of different perspectives on the topic or fast forward to minute 44 for the best part 😉

We thank the organizers API Evangelist and 3Scale for the opportunity to share our thoughts this way and feel privileged to share the stage with such renowned speakers and business leaders. Here’s the complete rundown of the video:

APIs and The Future of Data @ APIStrat. For more videos from the conference head over to YouTube.

SlashDB Adds Support for 3Scale API Management Service

SlashDB Adds Support for 3Scale API Management Service

powered-by-3scale-croppedWe are pleased to officially announce that we have added support for 3Scale API Management service in SlashDB.

Powerful Technology Combination

With /db‘s capability to generate API on the Fly™ directly from databases this level integration creates the most powerful combo to quickly and reliably launch, manage and safeguard REST/HTTP APIs. API metering, billing and developer portal management are only some of the features that 3Scale’s platform provides. But an API management service cannot build an API for you – that is what SlashDB does.

In the past this kind of integration required manual modifications to proxy configuration files, which although powerful can be cumbersome to do. Now, all that is required is to use 3Scale web-based GUI for proxy configuration to generate required files, which then can be simply uploaded to SlashDB. Of course, manual tweaking of the files is still possible so SlashDB clients get the best of both worlds so to speak.

API Keys

Related to 3Scale integration, added is the support for authentication with API keys. SlashDB has always allowed for stateless authentication using HTTP Basic Authentication but many developers are accustomed to the convention of an API key. SlashDB now supports both a singular API Key (user key) or a pair of Application ID and Application Key. The keys can be associated with SlashDB accounts (users), which in turn govern access to data resources and system features. For making API calls authentication keys can be provided as HTTP headers or in a URL query string.

Immediate Benefits

There is no faster way to an API than from one’s database and SlashDB excels at making the connection, thanks to these key features and benefits:

  • API on the Fly™ with multiple resource representations to suit every purpose
  • Data Discovery and search readiness to visually orient developer or analyst in data resources available
  • SQL Pass-thru to leverage the full power of database querying capabilities in API
  • Authentication, resource authorization and encryption to control who gets to see what
  • Leverages investments already made in databases for seamless integration with HTML5, mobile, NoSQL and Big Data analytics

Enterprises, web businesses, data vendors, data scientists, quantitative analysts, DBAs, mobile enterprise applications developers and other user groups all derive unique benefits from SlashDB.

How can /db upgrade your data infrastructure? Learn about solutions and try it risk-free on your databases.

Database Gateway for Mobile and Web Apps

Many organizations are now building dedicated mobile solutions and most of them will face a dilemma of how to access internal databases on those devices. Direct connection is not an option due to firewalls and neither is VPN because phones can go out of network coverage at any moment. Some fall back on periodic synchronization when the device is back in office but that is like going back 20 years to the old PDA days. In order to access the data in real time a web service needs to be developed. That has proven to be neither easy nor cheap nor fast to accomplish.

It all changes with SlashDB.

Once installed next to a web server, SlashDB connects internal databases to authorized mobile and web applications. Technically speaking, it automatically constructs a REST/HTTP web service, which makes database content accessible by URLs for reading and writing, under compatible data formats.

Using SlashDB, enterprises can create meaningful systems of engagements themselves or in partnerships with clients or 3rd party developers.

Diagram depicts SlashDB installed in DMZ

SlashDB as a Data Gateway (click to enlarge)

The benefits of HTTP APIs go beyond just modernizing the technology infrastructure and translate to competitive advantage for one’s business.

For example, an executive could negotiate a better deal by having an up to date inventory data on hand. The inventory itself could be accurately calculated because purchase orders were captured on the fly from distributor’s outside salesperson’s device into company’s database.

Systems or engagement are about interaction, in the moment updates and sharing but they make business sense only if they can work with and leverage prior investments made into the systems of record. SlashDB makes the connection.

SlashDB Applauded at PyData Conference

SlashDB lightning talk at the PyData conference was received with a round of applause. Please contact us to discuss /db features in context of your work or to schedule a dedicated presentation.

Turn any Database into an Online Resource with Assetcloud Powered by /db

Turn any Database into an Online Resource with Assetcloud Powered by /db

The news is outNovember, 14-15 we will be exhibiting /db at the NY Business Expo, booth #66 at the 69th Regiment Armory in New York City. Come join us, see /db in action.

Turn Any Database into an Online Resource with VT Enterprise Assetcloud Powered By /db

Financial industry first to adopt Assetcloud powered by /db to cope with data silos, become cloud-ready. Automatically generated REST API streamlines enterprise data management and paves the way for mobile enterprise applications.

Jersey City, NJ (PRWEB) November 06, 2012

VT Enterprise announces the immediate availability of Assetcloud powered by /db, a solution to the growing data access problem in financial industry. As institutions become increasingly information-driven, databases play a crucial role in driving critical business processes. However, organizations often encounter multiple databases in different departments that are hard to access. Assetcloud powered by /db solves this data management problem by instantly turning any group of databases into a “cloud” of online data resources that are easily searchable and accessible by authorized users and applications. [Read more]