Hacker News Reader

Comment by nona | Hacker News Reader

I hate to be critical considering the considerable work they've put in, but I don't buy their "JMAP is actually more REST-like than most “RESTful” APIs" statement. But maybe I'm missing a whole lot.

REST doesn't preclude doing multiple things in one round trip. Well it does seem JMAP is a bit more flexible when it comes to multiplexing very different actions. But the error handling doesn't seem to tell you which command has failed. You still can't get away from certain ordering issues. And to be honest, I don't see how it's going to be that easy to cache.

This really is RPC – using it as a straight replacement for IMAP might work well, but I wouldn't want to use it as a platform to build something very different than an email client on it.

View on HN

Each call is tagged by the client and the same tag is added to the response by the server, so you can tell exactly what error corresponds to which call.

Caching is pretty easy: you just keep a cache of each object type. The delta update mechanism means you can very accurately invalidate what you need to keep it up to date. The system is actually really flexible and a great fit for any CRUD based app; JMAP is really just a combination of a very powerful and efficient database access protocol, and the definition of some objects to represent email, contacts and calendars.

Not just some objects, but different methods to access different objects, and it's those methods that implement the semantics - the base of JMAP is just an encoding for bulk RPC.

What I mean is, if tomorrow I add a file with the mediatype application/vnd.icebraining to my server, an intermediate HTTP proxy can still cache it even though it knows nothing about my format.

But if I add a new object (say, Note) to my JMAP server, along with the appropriate methods (getNotes, getNoteUpdates, etc), an intermediate JMAP server will be unable to cache them, since it needs to know the semantics of the new methods.

So frankly, I don't see how their protocol follows an uniform interface at all.

I still think it's pretty neat, though, don't take me wrong. I just want people to stop abusing REST. There's nothing wrong with RPC!

While I agree with you that in general there's nothing wrong with RPC, I'm not sure what the advantage in this case is. You seem to have an idea, though…?

Oh, you'd have to ask the JMAP devs. But I do think they'd have to bend the constraints pretty hard to have a RESTful interface while keeping the same advantages w.r.t. efficiency in the number of requests and data transferred.

Like Fielding writes in his dissertation, "The REST interface is designed to be efficient for large-grain hypermedia data transfer, optimizing for the common case of the Web, but resulting in an interface that is not optimal for other forms of architectural interaction."

Oh right, now I see the: ["error", { type: "unknownMethod"}, "client-id"] -bit. Still, it sounds like you're reinventing HTTP verbs and statuscodes and embedding them inline in the JSON just to be able to multiplex the calls. Might as well use HTTP2 or SPDY, then.

Also, caching JMAP may be easy on the client side, but not for any intermediate cache - unless it understands JMAP.

I'm not saying RPC over HTTP is bad, mind, but you do seem to lose some of the benefits of HTTP.

Approximately nobody likes having intermediate caches that can cache their https traffic.

Approximately even fewer of the people here at HN like the idea of their email messages behing sent over non-secure channels.

At least we're not embedding HTTP status codes in XML...

Reply on news.ycombinator.com