What do you mean by "does not seem RESTful"? It's a set of data. Writing a webmail app should be more like any other CRUD app. I don't see why that damages atomicity. Nor do I see why synchronous command requests are a problem, this works fine for AJAX. Especially if you can issue more than one at once. Store the mail in MongoDB or similar (possibly detatching the bodies of large mail for storage convenience). Stop using rfc822 as the wire format.
"Move" is greatly simplified if "location" is a tag field like gmail rather than anything to do with filesystem storage.
The purpose would be building web apps that manipulate email.
The question is why you think a RESTful data model fits the problem. It is a model that fits when resources are published globally, when the CRUD methods are enough, whose purpose is to enable global caching and make hyperlinks possible.
Pretty much none of this is true for email. You don't even want global caching here. You want responsivity, and a rich and extensible data model.
How would you move an email? How would you control whitelisting? Spam scoring? Folder ACLs? How would you sleep until a mailbox changes? Even if you _could_ represent these things as resources, it's going to be much more hairy than IMAP with the performance of POP.
The evolution of email has been completely opposite of dumbing it down. Users expect calendaring and global contact lists, and here you have the impedance mismatch _again_. Look at the mess that is CalDAV, and that's DAV which is much richer then REST.
Regarding asynchronous commands, I don't know what you think it has to do with AJAX. It is the Javascript that is asynchronous in AJAX, not the HTTP requests. Web browsers typically implement it using multiple connections. This is a problem. Do you really want connection pooling (so a server can serve _fewer_ clients)? No, you want an evented protocol. Such as IMAP.
And again, you probably could do it given enough work and come close to the performance of IMAP for most end users, but why would you? It doesn't really map to the REST architecture.
It you would rewrite your comment but s/REST/RPC/ I would not object to it. I would just think you were from the past :).
Are you arguing that the correct way to do webmail is to have an IMAP client in Javascript running in the browser? I think we're talking at cross-purposes here. Suppose I am writing a webmail client. Suppose I am doing this in the usual modern way of writing web applications, which is to retrieve data in JSON or XML and render it client side. I wish to retrieve some data items called "email headers" and "email bodies". I want the backend to look as much like a database as possible, relational or non-relational. I want the backend to explode mime/multipart, canonicalise things as UTF-8, fix quoted-unprintable etc. That's the application I'm aiming at. Furthermore, I'd like to standardise the transport layer enough that people can write interchangeable web frontends.
As far as I know IMAP itself doesn't have any features for whitelisting and spam scoring? Nor calendaring nor global contact lists?
"Move" email specifically would be implemented as updating the "location" table. An email would be allowed to be in multiple locations (qv gmail labels).
Am I that unclear? No, I'm not arguing that the correct way to do webmail is to implement IMAP in Javascript. (How would that even work?)
I'm arguing that a RESTful implementation of the same functionality IMAP offers would -- by necessity -- have problems with responsivity and/or concurrency. Webmail clients should be a case in point here.
Do note that when Google implemented the GMail app for Android, they created a protocol that looks a lot like RPC and is nowhere near REST. These people are not stupid and if the REST architecture made sense for mail clients you would see it reflected there.
"Move" is greatly simplified if "location" is a tag field like gmail rather than anything to do with filesystem storage.
The purpose would be building web apps that manipulate email.