4 ms·

> How would you explain [complicated query params] to a nontechnical person? 1) A lot of people actually get what ?foo=bar means in a URL. Especially when it i

by pdkl95 11y ago

> How would you explain [complicated query params] to a nontechnical person? 1) A lot of people actually get what ?foo=bar means in a URL. Especially when it is well named (e.g. "&page=3"). Is it really necessary to make URLs overly complicated? 2) Why would anybody - with or without a technical background - write a complicated query UR by hand? That's what <form> is for. 3) The entire premise is based on the "poor non-technical user"... who is writing a query string for an API? This is a complete straw man. > Two endpoints is good enough for most people for web application programming. "web application"? The example was a (fancy) search form to retrieve articles. That's not a "web application" in any way. Each article should have it's own URL, and search (even complicated search, progressively enhanced to dynamically load the results) was a solved problem a decade ago. It is inappropriate to render this on the client, and trying to limit to two public URLs screams that this is a cheap attempt to defeat deep linking and create yet a walled garden. Stop trying to make the web back into TV. > You can play with it and the StarWars API An entirely broken demo. Sending an empty body tag is not useful page. There isn't even fallback text, so it just looks broken when the incorrect assumption that "everybody has javascript" fails.

ludwigvan 11y ago
Hi there, thanks for the comment. Author here. No, poor technical user is not the entire premise. What I was trying to convey is to give the reader a chance to reevaluate the decision to send parameters that way, rather than trying to accept it as it is. It is hard for experienced people to think that way because they have become accustomed, but most of the time, in programming, we don't realize simpler solutions are possible. It helps to reevaluate from the eyes of a beginner. Rich Hickey has a great talk on this called Simple Made Easy: http://www.infoq.com/presentations/Simple-Made-Easy http://www.infoq.com/presentations/Simple-Made-Easy > web application The blog post mentions getting an article, but basically the web applications nowadays move complexity to the client and see the server as a single API. Having that as a single URL is the natural derivation of that. Any request queries or mutations are sent to that URL. I have updated the demo link so that it now starts with a real query, rather than an empty page. See an example at: http://bit.ly/1Qa4h00 http://bit.ly/1Qa4h00
- pdkl95 11y ago
  > 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.
  - ludwigvan 11y ago
    Try this: curl 'http://graphql-swapi.parseapp.com' \ -H 'content-type: application/json' \ --data-binary '{"query":"{ allFilms(first: 3) { films { title, director } }}"}' The query param is just for easy sharing online when you build a query.
    - belovedeagle 11y ago
      > The query param is just for easy sharing online when you build a query. Gee, if only there were a way to encode that data into the URL itself without embedding an almost-JSON document! Someone should invent something like that.

by pdkl95 11y ago

ludwigvan 11y ago

Hi there, thanks for the comment. Author here. No, poor technical user is not the entire premise. What I was trying to convey is to give the reader a chance to reevaluate the decision to send parameters that way, rather than trying to accept it as it is. It is hard for experienced people to think that way because they have become accustomed, but most of the time, in programming, we don't realize simpler solutions are possible. It helps to reevaluate from the eyes of a beginner. Rich Hickey has a great talk on this called Simple Made Easy: http://www.infoq.com/presentations/Simple-Made-Easy http://www.infoq.com/presentations/Simple-Made-Easy > web application The blog post mentions getting an article, but basically the web applications nowadays move complexity to the client and see the server as a single API. Having that as a single URL is the natural derivation of that. Any request queries or mutations are sent to that URL. I have updated the demo link so that it now starts with a real query, rather than an empty page. See an example at: http://bit.ly/1Qa4h00 http://bit.ly/1Qa4h00

pdkl95 11y ago
> 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.
- ludwigvan 11y ago
  Try this: curl 'http://graphql-swapi.parseapp.com' \ -H 'content-type: application/json' \ --data-binary '{"query":"{ allFilms(first: 3) { films { title, director } }}"}' The query param is just for easy sharing online when you build a query.
  - belovedeagle 11y ago
    > The query param is just for easy sharing online when you build a query. Gee, if only there were a way to encode that data into the URL itself without embedding an almost-JSON document! Someone should invent something like that.