> It is functions all the way down I came to approximately this conclusion a year or so ago, on my personal road of HTTP experience. I didn't even realize it w

> It is functions all the way down I came to approximately this conclusion a year or so ago, on my personal road of HTTP experience. I didn't even realize it was related to HTTP at the time: I wanted an RPC protocol that could do various things: It's just function calls, right? The thing was, the more and more I added features to it, the more and more it started to resemble HTTP. I think the final straw was caching: I needed a way to identify the resource to be cached, and eventually realized that identifier was a URL, and that the whole thing was essentially HTTP if I change from "function calls" to "resources". > The server receives two strings: the path and the query params (or post body as string). The first string is parsed to get the function to call and some parameters to be passed to that. The second string is parsed to get the additional parameters to be passed to that function. > We have been accustomed to getting JSON responses from the server. Isn’t it time to stop sending strings to the server and start sending a structured data format? To some extent, the data is structured. The path is hierarchical (though most web frameworks/servers I've interacted with do a crappy job of exposing that). With regards to the query string and POST body, I feel like the article is muddling the encoded (string) form and the decoded form. We have to encode to a string to transmit: it's going over TCP, or a wire even, at some point. But it's perfectly fine to put JSON data in a POST body. Even the default, x-www-form-urlencoded, is "structured" in the sense that it's key-value pairs, though perhaps less "structured" than JSON. (It has a well defined form, and a way to parse it, though it isn't as rich in what it encodes as JSON.) Near as I know, the query string can be JSON too; it just typically isn't by convention. I'm curious how this supposed "two URL" approach would attempt caching. I think the newly drafted SEARCH method[1] (intended for search requests; carries a body) would suit the example in the post fairly well. The body on that request could be GraphQL. (And today, if you really need a odd request like this with a body… there's POST.) [1]: https://tools.ietf.org/html/draft-snell-search-method-00 https://tools.ietf.org/html/draft-snell-search-method-00