Its been my experience that anything with Simple or Lightweight as one of the letters in the acronym is usually anything but.
This is part of a general principle that things with feelgood adjectives in their names usually don't really merit them.
The S stands for Simple
51–54 of 54 posts
Re: The S stands for Simple
#52Earlier quoted context omitted.
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…
Ah thanks. Just plain JSON RPC sounds simplest to me.
Re: The S stands for Simple
#53Earlier quoted context omitted.
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/Abstrac…
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…
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).
Re: The S stands for Simple
#54Interoperability is a vitally important but hard problem. CORBA and then SOAP have been thoroughly adopted, then widely condemned. What's next?
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.
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?