Looked at backbone.js and thought the same thing - overkill for what I needed. I'm always thinking "how will I scale this to portable devices", and one important consideration is code size. Plus IMHO HTML/JavaScript/CSS is quite MVC to begin with (HTML/CSS being the View, JavaScript of course is Controller logic, and just don't make the mistake of using the DOM as your data storage and use JavaScript objects for the Model). Maybe it depends on the complexity of the app, and I'd definitely look at agility.js first if I needed something since it's lighter than backbone.js ...
For building something that is content management, Django - as others have said - is a good choice. Going forward though, as a veteran C and web programmer I really like node.js. I think you will enjoy coding in JavaScript since it's like C syntactically, and you will really like the power and flexibility of node.js.
Also there are plenty of ORMs for node.js - I like Mongoose and mongodb personally, but there are several others.
I sort of like schema validation, but it makes it a pain to add things to your objects later if clients of your API are depending on that (they will break when you add something).
SOAP is really for client side programmers that can't figure out how to do an HTTP request and parse XML all by themselves. Also the sell is that you can use automation tools to generate your client side code for you, but I found that they do not all behave the same way when dealing with anything mildly complex (like an array of objects for example). Data streams are also a PITA to deal with in SOAP, there's really no good provision for it. So do yourself a favor and wash your hands of SOAP (ha ha!)
No, SOAP is for businesses that need a clear data contract in place when doing inter-business data integration with real money on the table. That's why it's been used in business APIs for nearly a decade. REST has nothing that parallels the functionality of a WSDL and all the tooling that has been built up around WSDLs. Without a WSDL, you don't have a computer-interpretable spec for the presented API, you have a bunch of human readable documentation, and REST has a huge gap between principles imposed by the philosophy and the protocol that allows for a wide variety in how APIs are designed. I don't think you understand the whole code auto-generation thing; SOAP can't generate much of the client-side code. It might generate the function signatures or an object that has the methods presented by the API. On the server-side, you can usually auto-generate a WSDL from a class definition or vice versa, which is a handy way to start turning that data contract into an implementation.
SOAP isn't going anywhere in the big-business world, but for smaller businesses/apps that can play faster and looser with data integration, I absolutely agree that REST is a simpler and more pleasant choice to work with.
Thanks, I was just thinking about this exact problem and wondering if localStorage would be a good way to handle it. It looks dead simple from your code - just set an attribute with the JSON request as the value, and try to send it later. Lots of little other things to work out like tommi mentioned, but nice simple examples are really helpful.
