4 ms·

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,

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.

InclinedPlane 17y ago
Not just JSON and HTTP but specifically REST w/ JSON. There's a lot to be said for such a model.
- garnet7 17y ago
  What's the difference between "JSON in GET/POST" and "REST with JSON"?
  - carey 17y ago
    "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.
  - JulianMorrison 17y ago
    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.
    - garnet7 17y ago
      Ah thanks. Just plain JSON RPC sounds simplest to me.
10ren 17y ago
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_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?

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.

InclinedPlane 17y ago

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

garnet7 17y ago
What's the difference between "JSON in GET/POST" and "REST with JSON"?
- carey 17y ago
  "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.
- JulianMorrison 17y ago
  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.
  - garnet7 17y ago
    Ah thanks. Just plain JSON RPC sounds simplest to me.

10ren 17y ago

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_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?