Pedantically, RESTful APIs do not maintain session state on the server. This is important for scalability.
(Whether "pure" REST is appropriate for a given API, or will be adopted if it is, is another question.)<p>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.<p><i>EDIT</i> 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 <i>that</i> to be your RESTful API.<p>This doesn't sound right - it's certainly not a conventional RESTful API - but what exactly is the problem with it?<p>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.<p>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).
If a "BaaS" for a web app sounds appealing, try <a href="http://github.com/adelevie/parse_resource" rel="nofollow">http://github.com/adelevie/parse_resource</a>.<p>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.<p>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.<p>I'm fairly active in developing it, and would really like some feedback, feature requests, and contributors.
The MongoHQ API is making great strides moving in this direction and as was mentioned in another post, the team is dog-fooding it so much that they are building the next version of the MongoHQ web app on top of it.<p>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.<p>Really excited about this type of development going forward and good to see other offerings in the works!<p>(full disclosure: I am one of the founders of MongoHQ.)
I've written a small ajax wrapper for Parse.com's API.<p><a href="https://github.com/srhyne/jQuery-Parse" rel="nofollow">https://github.com/srhyne/jQuery-Parse</a><p>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.<p>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.
See CouchDB.<p>What is CouchDB?<p>A document database server, accessible via a RESTful JSON API.<p>Ad-hoc and schema-free with a flat address space.<p>Distributed, featuring robust, incremental replication with bi-directional
conflict detection and management.<p>Query-able and index-able, featuring a table oriented reporting engine that uses JavaScript as a query language.<p><a href="http://couchdb.apache.org/docs/intro.html" rel="nofollow">http://couchdb.apache.org/docs/intro.html</a>
Sick of seeing projects that use twitter's bootstrap I'm building a simple api only cms: <a href="https://github.com/gvnn/flatwhite" rel="nofollow">https://github.com/gvnn/flatwhite</a>. It's a simple project that I'm using to teach myself node.js... in the future would be great if users can define their data structure and execute CRUD operations via REST calls
The wheel of reincarnation spins.<p>We distributed the intelligence from the mainframe to minis/workstations and then later PCs.<p>Then we re-centralized it to the datacenter/cluster with the web browser 1.0.<p>Now we're redistributing it to the browser (thin clients finally win).<p>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.
I was looking at kinvey.com mentioned in the comment of the article while researching an alternative for Adobe Publish at work. Their 1-2-3 explanation on the home page is compelling, except for the 1 part. Yes, one should have the option of creating or extending a custom model, but why not have a library of pre-built solutions? "Here's our e-commerce starter kit, it's got a cart, products, customers, tax tables, and inventory management. Also we built an awesome back-end and some integrations with these payment processors." If you're building a BAAS, why not pick three or four common web-app types and make the models for them.
In fact, there are several such backend-as-a-service offerings in existence already, including StackMob -- a ycombinator company if I'm not mistaken. And note that any such BAAS that can be used for mobile development can just as easily be used for desktop web development. More and more desktop web apps are doing most or all of their logic locally using Javascript and then accessing their servers RESTfully for data persistence. StackMob is well-positioned to take advantage of both the surge in mobile apps and these new trends in desktop web development.
Isn't this what frameworks like rails, grails and spring roo are for? They make creating a basic CRUD app trivial. If you just need a trivial app then use one of these frameworks, anything more is obviously going to require customization on the backend code. I suppose there could be a niche for managed RAD (rapid application development) packages, or something like that, where they help people build an app using rails, or something, and then host it, but its not nearly as groundbreaking as seems to be suggested, these frameworks are fairly trivial to use as is to get basic CRUD functionality and if you need more customization then you're already moving out of the territory of having the backend as a service without having to pay custom development rates.
On the REST part it is not ideal for complex object based system where there are multiple resources which have n number of relationships and different http verbs on them can be mean different operations when exposed in a different way. ( I know its confusing.. :)). I just look at it as a design pattern which makes client side devs consume your services easily. It definitely helps in creating simple webservices but REST as a whole I would say doesn't satisfy everything a backend developer would want to expose or do in an efficient way. Think of batching... in REST.
Many developers are already using our StorageRoom CMS (<a href="http://storageroomapp.com" rel="nofollow">http://storageroomapp.com</a>) for this.<p>An administrator configures content types, editors manage the content and developers fetch the content through the RESTful JSON API (including CORS & JSONP support).<p>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.
This highly depends on the kind of apps which needs to be done. Its highly difficult to generalize a backend for a n number of apps. I am not comparing the term "backend" here with Parse or YQL or aggregating datasources which is great. You write a backend to custom suite your app so that its highly performant both on the client and server side and you have paas hosting services for the language of choice. I would personally not like to have a generalized backend.
Disclosure, I work for Zipline Games on Moai Cloud.<p>Moai Cloud (<a href="http://getmoai.com" rel="nofollow">http://getmoai.com</a>), 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.
There cloudmine.me also. They are providing similar services. I think mobile BAAS is a limited market. But, domain based BAAS is a huge market. You can never build a backend model to suffice the needs of different mobile apps. It will be difficult to build a backend model for EMR system but providing a backend model to convert dicom data for consumption on a mobile platform will be a good service.
My startup is building a BaaS that focuses on flexibility and any client not just mobile. We are working on Javascript bindings to improve ease of use but it has REST endpoint that uses JSON. You can read more about it at <a href="http://iknode.com" rel="nofollow">http://iknode.com</a>
RunMyProcess a startup from Paris, France does this. <a href="http://www.runmyprocess.com" rel="nofollow">http://www.runmyprocess.com</a> . I teach university students how to use this. Impressive product. Sort of like an enterprise-level configurable IFTTT.
That's what these guys are doing: <a href="http://www.ibcom.com.au/" rel="nofollow">http://www.ibcom.com.au/</a> despite a bit of a naff web presence I've had a peek under the hood and they're doing some really interesting stuff.