Hacker News Reader

Comment by nmjenkins | Hacker News Reader

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.

View on HN

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