If too much is done on the client-side, it loses some of the benefits of webapps, such as easier to pirate the working code; so the competitive advantage needs to be in the data (or in the server side processing) rather than the client app itself.
EDIT There's a general problem with RESTful APIs: they are fixed and can't be adapted to every use. You might end up doing a lot of transformation on the client side to assemble the info you want, and it might take several calls, causing latency. What's needed is something like relations and SQL, so you can extract the data in whatever structure you need, taking into account latency (assembled on the server, the message short though including oft-needed related data, and minimizing slow network trips). An obvious solution is for the server to just accept SQL directly - i.e. for that to be your RESTful API.
This doesn't sound right - it's certainly not a conventional RESTful API - but what exactly is the problem with it?
I think we don't have it yet, because there isn't a need for it in these early days - because, so far, it's common for one server to be used by just one client application, so that they are specifically customized for that one use-case. But what will happen when several different client applications want to use the same server? Secondly, these APIs are new, and there has been little time for them to change much, so the problem of compatibility with old clients hasn't arisen much.
SQL solves both these problems, of different application and of changes, but these problem don't exist so far. And I guess it's not certain that they will exist - if clients are always silently upgraded; if for a second app you just create a second RESTful API for it (so the integration occurs further back, at the database, instead of at the API).
This isn't REST as such, in fact you have the same issue with any service API.
Solutions include creating composite resources, see Subbu's (excellent) REST/HTTP book which discusses it.
Its also worth noting that more granular resources can have advantages particularly when mutability is considered. So if you combine mutable data with immutable data, and in addition the mutable data changes to very different schedules, then taking advantage of HTTP caching becomes more difficult. So if you create more granular resources but some of them are very cacheable then you can actually in some cases get less latency.
> SQL solves both these problems, of different application and of changes, but these problem don't exist so far.
I haven't had time to play with it but ql.io is designed to address these issues and might be worth a look:
HTTP is a pretty sophisticated protocol, when all is said and done. That means there is a learning curve in using it effectively. However, a good BaaS takes care of that for you, including providing default client libraries that know how to take advantage of the API properly.
(Full-disclosure: my company, spire.io, has recently launched a REST API BaaS that attempts to address exactly these concerns.)
I imagine the session state would consist of client side Javascript (since this service would be ideal for the type of single page apps served well by Backbone.js and the like). The javascript would probably submit time-expiring authentication tokens with each request. That way, session could be persisted client side, while maintaining permissioned access to the CRUD actions on the service side.
EDIT (to respond to 6ren's edit):
I agree that, in a production environment, the flexibility of the rapid prototyping could, in many cases, turn into rigidity when faced with just a RESTful API.
But not necessarily in all cases, especially when implementing a single page app style site, where you are more likely to persist data client side in the background for when you need it.
Ultimately, I think the tradeoff might be worth in some circumstances. And given the apparent success of the many mobile BaaS solutions, it seems to be often enough to capitalize on.
On 6ren's rigidity argument, relations and SQL are still not enough to guarantee you'll always be able to get the data you need; notably, when the data model changes. Backward compatibility is important and we might have they only solution that guarantees it.
It provides a very rich query API on top of basic http, and as you can see works naturally with REST services. I'm not aware of how other frameworks provide OData support, but some quick googling reveals that most web frameworks have odata libraries available.
It's an incredibly bad idea to allow SQL directly, for obvious reasons (would require executing user provided SQL among other things.)
I believe that having a single REST api that serves multiple front-ends (web, mobile, thick client etc) is the future as it removes the need to maintain an entirely different codebase just for a web interface. Indeed, many major websites have moved to this model.
Could you elaborate on this? I've been thinking about providing SQL access to a data-heavy service, but I keep hearing that you never should.
(Almost) all servers have granular access-control, views can further provide limited views of the data, SQL itself is mostly declarative, which makes it possible to analyze the queries before running them, and logging and setting limits on long-running queries is standard.
Surely other keywords could be added as well (e.g., specifying a set of resource fields, ordering, etc). A RESTful solution, although probably not quite elegant.
[1] http://www.stereoplex.com/blog/mobile-api-design-thinking-be...
The primary client for an API I'm currently working on is an iOS app, so for the web version of the client, it just made sense to build on top of the same OAuth-authenticated API. Instead of traditional sessions, we store the access token in a cookie and sign each authenticated request just as you would any third-party API.
What is CouchDB?
A document database server, accessible via a RESTful JSON API.
Ad-hoc and schema-free with a flat address space.
Distributed, featuring robust, incremental replication with bi-directional conflict detection and management.
Query-able and index-able, featuring a table oriented reporting engine that uses JavaScript as a query language.
In CouchDB, if you want to change your schema you just save the new data.
Your code will have to handle the old and the new form, but that is always true. In CouchDB the data is just a JSON document, so handling the changed model is about as easy as it gets.
What am I missing?
It lets you use Parse in a Ruby/Rails app with a very ActiveRecord-y API. By using it, your web app gets the following for free: documented REST API, documented iOS and Android SDKs, and the guy who helped scale Scribd is your DBA.
I've been using parse_resource to make some throwaway apps, and I'm currently "dog-fooding" it for a production app. I've found that the schema-lessness and zero-db-admin makes prototyping a snap.
I'm fairly active in developing it, and would really like some feedback, feature requests, and contributors.
We do believe the BaaS model can extend far beyond our current mobile focus. We have a full REST API upon which many people build rich web apps, desktop apps, and much more. Third party libraries like Alan's excellent ParseResource have been great enablers.
I'd encourage everyone to give Parse a try and keep an eye out. We plan to expand our selection of officially supported SDKs soon.
The added benefit that we see is that we are experts in managing, optimizing and scaling all of the backside data structure for you, while offering solid analytics, performance metrics and visual tools that allow you significant control over your data as well as critical insight into what is happening.
Really excited about this type of development going forward and good to see other offerings in the works!
(full disclosure: I am one of the founders of MongoHQ.)
I'm considering using mongo in the cloud but the problem I see is that there's no way to create a secure (encrypted) connection. Mongo doesn't support SSL and I can't create an SSH tunnel like against a server I control. I don't want my db data in the clear on Internet and I may not want to use AWS so that we're on the same 'network'.
I cannot be the first with this issue, is someone looking into adding encrypted connection to mongo? (I just see in mongo's site an open ticket about this) thanks!
Encryption is a common request for mongo and you can actually compile it with ssl support (scons --ssl), but it just isn't in the build by default.
Since most of the drivers support ssl already we leverage that and do offer encrypted mongo in a beta. If you would like to use an encrypted version of mongo in the cloud then shoot us an email to support@mongohq.com
https://github.com/srhyne/jQuery-Parse
Just $.parse.get/post/put/delete is needed; served from file:// or a Chrome extension and you have a completely client side prototype or internal business tool.
I'm really excited to see StackMob, Parse, and MongoHQ take off. Talking to one of the MongoHQ guys at MongoDB Seattle and they mentioned they were working on some kind of client side authentication system. jsOAuth is cool as well with StackMob.
We distributed the intelligence from the mainframe to minis/workstations and then later PCs.
Then we re-centralized it to the datacenter/cluster with the web browser 1.0.
Now we're redistributing it to the browser (thin clients finally win).
Sadly, it appears that the democratizing effects of the PC revolution won't apply when the code is delivered from a centralized server. Doing the computation at the edge doesn't subvert control if the code comes from the center. That (absent possibly impossible in practice cryptographic measures) jailbreaking edge devices is possible isn't terribly relevant if 99.999% of folks can't even understand the things they could do with a jailbroken device.
An administrator configures content types, editors manage the content and developers fetch the content through the RESTful JSON API (including CORS & JSONP support).
How is it different to Parse/StackMob/Kinvey? It is more about delivering editorial content to mobile or web apps and not about a read/write backend.
Moai Cloud (http://getmoai.com), while focused on enabling backends for mobile games provides some of what you describe. We use mongo on the backend to provide schemaless storage and are building out a set of RESTful apis. Additionally if you need to you can write and run your own custom code on the server.
SAAS - HTML = BAAS