> we don't realize simpler solutions are possible I'm not seeing a "simpler solution" - your URL is far more complex, and is probably even harder to parse by p

> we don't realize simpler solutions are possible I'm not seeing a "simpler solution" - your URL is far more complex, and is probably even harder to parse by people that have learned how URLs work. Making non-technical people learn yet another new way to do things isn't helping. Also, at some point, you're just going to have a complicated interface. T > move complexity to the client It's not your computer, so you don't get to decide how the client handles the page. If you want your content to be read, try actually sending it. Note that this is a statement of fact, not an opinion about how I wish computers worked. You do not know what the client is doing when it renders a page (adblocking is a common example), so moving complexity to the client unnecessarily is risky. So far I'm still only seeing a search interface, which is (by definition) purely server side. > sent to that URL Ok, I think I get what you're excited about: you're reinventing #respond_to/#respond_with[1], so the URL can be reused for different mime-types. [1] http://edgeapi.rubyonrails.org/classes/ActionController/Responder.html http://edgeapi.rubyonrails.org/classes/ActionController/Resp... > rather than an empty page. (by the way - curl complains about that URL. Something about bracket? It may be some advanced feature of curl? No matter, wget is fine) $ wget -O /tmp/page.html 'http://graphql-swapi.parseapp.com/?query=%23%20Welc ... %0A}' $ </tmp/page.html sed -ne '/<body>/,/<\/body>/ p' | sed -e '/<script>/,/<\/script>/ d' <body> </body> It's still an empty page.