Udi explains why Mean Fiddler only supports GET

In my Mean Fiddler post I wrote that the service doesn't support all of the features of the Astoria framework. Many of these, such as ordering, skips and tops aren't there because I've been lazy. The service uses NHibernate's criteria API for perform queries, so it is straight forward to add OrderBy, Skip and Top criterions to the criteria query. Another "missing" feature is the ability to do create, update and delete operations. There is a reason why I didn't pay much attention to these; I see lots of issues with letting clients do data access on their own. After all you short-circuit the business tier with Astoria / Mean Fiddler. Udi Dahan has some great posts going into details on the issues with this. Read them here and here.

Astoria is not the first a good REST API for data access I've seen. In the speaker's lounge at last year's JavaZone conference, Bruce Tate showed me a similar service built on top of Ruby on Rails. I've also seen a new, cool application server for "the other platform" which has a similar concept. Unfortunately that one is under NDA, so I cannot be specific about what it was. The thing both of these had in common was that it was a nice way to do queries and none of them supported write operations. I see a place for REST-style querying, but writes bring to much complexity to the table when you move beyond the demos adding new products to the Northwind database. How will collections be handled? If I update a customer without supplying any orders, should I delete all the orders for the customer or should I leave them? If I leave them, should the client be responsible for deleting them if that was the client's intent? If so, how can this run in a transaction to ensure integrity when everything is POH (Plain Old Http)?
I could go on like this forever. I'm aware that some RESTful data APIs such as Google's GData service have features to workaround concurrency issues, but that still doesn't solve the semantic issues. If you have to resort to placing the data integrity logic in triggers within the database, you're two steps back from layered architectures. And if you're doing business logic in the database, why not just let the clients connect to the database directly (yes, I'm aware of the connection issues here) rather than introducing lots of abstractions in between?