The Mongo database has a great REST API, but you can’t use it. They tell you this right in the docs:
“Please note that this apiKey will give full access to all data within the databases belonging to your MongoLab account. If you do not have it secured on an app server, someone can gain access to it and your data.”
In other words, you must include your API Key in the REST request to connect to your data. So this API cannot be used from a client. In a native application these credentials could be found in the binary source code or sniffed network traffic. In HTML5 someone could simply view the source and grab your master credentials. This API can only be used from a server.
The Amazon S3 document storage system also has a REST API, but you can’t use that, either. Here’s how they explain it:
“You then use your AWS secret access key to calculate the HMAC of that string… Finally, you add this signature as a parameter of the request by using the syntax described in this section.”
In other words the secret key must be used to create each API request. If someone gains access to your secret key then they have access to all of your data. Not just your S3 files, I’m talking about ALL of your Amazon Web Services. Once again, you need a server to use S3 or other Amazon services.
What about Windows Azure? Here is how they tell you to create an Azure BLOB or Azure Tables account:
“The Create Storage Account operation creates a new storage account in Windows Azure. The Create Storage Account request may be specified as follows. Replace <subscription-id> with your subscription ID in the following URL…”
So once again, you cannot use these services from HTML5 or from a native application without fear of having your master account exposed. So you must build a server to use these powerful services. Well, if you’re going to build a server, you might as well build a good one. Here are some of the issues you will probably want to think about:
1) Your server must hide the master credentials to all the remote services you need like MongoDB, S3, and Azure. This way your individual accounts with Rackspace, Amazon, Microsoft, etc. cannot be hacked.
2) Meanwhile, you must provide client access to these services. User management capabilities and single-sign on with password hashing and time sensitive session IDs are the best practice here. Now add powerful CRUD roles and permissions by user to safeguard data access.
3) You don’t want to rebuild your server over and over in the future. You need a comprehensive palette of services for all the modern capabilities you might need such as SQL data, NoSQL data, BLOB storage, application hosting, email, and external services.
4) While you are at it, might as well simplify the wildly different interfaces these guys use to talk to all their different services. Every single one of these beasts will need to be tamed with a simple, clean, easy to use REST interface that supports native JSON objects.
5) Make your service interface lightening fast with carefully optimized code, and then conduct some load testing in the real world with tens of thousands of users. Now you are ready for a security audit.
6) Be sure that you have solved the “originating host” problems for HTML5 users. They will need to access all these services from a single domain. A nice feature to add would be programmatic CORs access so that they could use your services from other domains if needed.
So that’s the bad news. In order to use powerful services for your next application you are going to have to build a sophisticated server.
But finally, some good news: we have already built this server just for you. The DreamFactory Services platform does all of this stuff. We’ve been working hard on this project for years. You can try it out at our website www.dreamfactory.com or install the open source software package on your favorite cloud for free. There is a REST API for everything you need. In fact you won’t need to do any server side programming at all. Just go write your application.
So what are you waiting for?