Frankly I think there's some kind of Godwin's Law going on here, where something is insufficiently Enterprisey until an 'S' is attached to it, whereupon IT folks and professional donut-stuffing standards committee complexifiers wade in, and three linear bookshelf feet later you've got a Standard. And it's Simple. And all the devs who use it, who have a clue, just want to commit Suicide.

But maybe it's just me.

JSON in HTTP GET/POST. It's more of a nuisance, but it forces you to face the network issues head-on, and code that reads JSON can't afford to make assumptions, so it ends up less brittle.

Not just JSON and HTTP but specifically REST w/ JSON. There's a lot to be said for such a model.

What's the difference between "JSON in GET/POST" and "REST with JSON"?

In one, you are essentially doing RPC: here's the input, do the operation and give me an output. In the other, you are remotely manipulating "documents". Even a command to act consists of emplacing a "request" and being redirected to a "response". You navigate between "documents" by following URLs in links.

To be honest, I like REST for CRUD of things that are natural resources, but I think it's wasted extra work for operations that are natural RPCs.

Ah thanks. Just plain JSON RPC sounds simplest to me.

"REST with JSON" should send the (relative) URL for the next request, not just an ID. Although there's more to it than just that.

Thanks! So, the XML/SOAP/WS stack tried to simplify/abstract too much or wrongly, when problems leak through, it is too impermeable to let you solve them...

The "nuisance" of JSON+HTTP is a backward step in a way, but it lets you solve those problems. Sounds like an ideal solution would be an abstraction with less nuisance, that solves the network issues that it can and gives you access for the others - which may or may not be possible; it's an ideal.

(1) By "network issues" do you mean along the lines of Peter Deutsch's "8 Fallacies of Distributed Computing"? http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Comput...

(2) Regarding "assumptions" and "less brittle", do you mean issues of reading the format correctly, in the face of evolution of the internal structure and/or wire format?

REST, Thrift, AMQP + protobuffs.

http://incubator.apache.org/thrift/ http://en.wikipedia.org/wiki/Advanced_Message_Queuing_Protoc... http://code.google.com/p/protobuf/

Sounds intriguing - can you elaborate on why this combination is favoured in particular? Or point to an article that discusses it? It's hard to get widespread adoption if it's not accessible...

incidentally, google protocol buffers seems similar to http://en.wikipedia.org/wiki/Abstract_Syntax_Notation_One (ASN.1), which predates XML, but didn't take off.

ASN.1 actually did take off, somewhat, at least in telco. And after comparing thrift to protobuffs to ASN.1 for our internal protocol I ended up chosing ASN.1, mostly because of the great ASN.1 support in the OTP (I'm using Erlang). Erlang protobuffs library, on the other hand, is somewhat lacking and is terrible at encoding/decoding huge messages with big lists.

And AMQP was chosen for the transport layer because it handles persistent messages, transactions, all the routing, buffers messages, etc., etc. I'd have to implement all of these myself, had I chosen thrift.

This is how I ended up with RabbitMQ and ASN.1.

Thanks. The long-term trajectory of programming tools seem to favour developer ease over raw efficiency, as computers get faster but programmers don't (though possibly this might change as Moore's Law diverts from speed increases to multi-core).

Therefore, XML became more popular than ASN.1. I think the successor to XML (and SOAP etc) will be more human-friendly than XML, rather than more efficient.

That's not to say that extremely efficient techniques don't have a place (they do) or they're not cool (they are).

I actually coded one of Facebook's coding puzzles (Battleship) using Thrift and was pleasantly surprised. It provides support for many languages and getting up and running was a snap. I hope it catches on.

I like the MQ stacks (particularly ActiveMQ). I've used a proprietary message bus in the past and it was really nice to just send and receive message at the application level. Of course migrating to an asynchronous model of development can be challenging for some.

bert-rpc.org

I hope not. Between Protobuf and Thrift, I don't see the point of adopting a less efficient, even more niche NIH serialization format and RPC protocol.

Might be different if there were already numerous libraries that supported it but honestly if the extent of it is support in four languages (plus a few more that support the serializer) it's probably not worth wasting the effort unless it differentiates itself substantially from the existing solutions.

Both protobuf and Thrift are designed exclusively around simple static type-checking with type-erasure. Neither support heterogeneous collections, much less discriminated unions or GADTs.

There are plenty of untaken vertices in the serialization-format hypercube.

Heterogeneous collections, discriminated unions, and GADTs can be implemented easily in either thrift or protobuf by leveraging inclusion of custom type-tagged messages/data.

However, while the encodings are absolutely sufficient to represent these data structures -- if you so choose -- my experience dictates that keeping serialized messages typed and as simple as possible is advantageous from the perspective of long-term maintenance and interoperability.

Of course you can implement custom type-tagged blobs, but that's not using thrift or protobufs -- it's your own nebulous SOAP-style bullshit.

They're not "blobs" if they are also protobuf/thrift messages themselves.

That's certainly cleverer, but it's still a nested user-implemented unsound type-system.