[nmjenkins]

(Author of the spec here)

REST is way too slow. The JMAP format massively reduces round trip times, especially when you have sequential operations where you must wait for one to finish before the next can happen. And once you're not doing REST, I don't personally think putting HTTP verbs in the method calls doesn't really make it any clearer, and is just likely to confuse matters.

[mercurial]

> The JMAP format massively reduces round trip times, especially when you have sequential operations where you must wait for one to finish before the next can happen.

I hear you (REST and batch operations don't mix too well). But wouldn't it be possible to simply provide higher level operations, grouping several of these commands?

> And once you're not doing REST, I don't personally think putting HTTP verbs in the method calls doesn't really make it any clearer, and is just likely to confuse matters.

As I said, it wouldn't necessarily be restricted to HTTP verbs (eg, using 'create' and 'update' instead of 'POST' and 'PUT'), but I do like the idea of separating the resource you act on from the action on this resource.

[nona]

I didn't take the time yet to have a proper look at it, but nothing stops you from doing batch REST operations on collections. You can do compound documents - with references - à la jsonapi.org. One thing I would consider essential though, is using RFC2518 MOVE, COPY etc, you really want to do those server-side.

Do you have an example of the type of operation that would map poorly to REST?