Half a croissant, on a plate, with a sign in front of it saying '50c'
h a l f b a k e r y
You think: Aha! We go: ha, ha.

idea: add, search, annotate, link, view, overview, recent, by name, random

meta: news, help, about, links, report a problem

account: browse anonymously, or get an account and write.

user:
pass:
register,


               

URL Symbol for POST Requests

URLs that mutate data. POST (!=some&data)
  (+2)
(+2)
  [vote for,
against]

Our browsers do not send a POST request explicitly via address line. So, whenever we try to open a web page by URL, we always are sending GET (? some=data) requests. But what about updating data on resources? Introducing the POST (!=some&data).

For example, if we chose this symbol to be "!", then, if you want to mutate data on an endpoint, you'd simply query your browser address by a link:

http://example.net/endpoint!param=val

And visiting it, the browser would send a POST header to the endpoint, serializing data for the body from its URL parameters.

Mindey, Oct 29 2019

Wikipedia https://en.wikipedi...ubmitting_web_forms
(POST) html [FlyingToaster, Oct 29 2019]

[link]






       The Wikipedia article on POST contains the line "when a browser sends a POST request..."
FlyingToaster, Oct 29 2019
  

       Which version of Wikipedia article? [FlyingToaster]
Mindey, Oct 29 2019
  

       <linked> : I don't know anything about the subject, myself, mind.
FlyingToaster, Oct 29 2019
  

       You can easily manipulate POST data using the dev tools built-in to almost all browsers.   

       Putting POST data in a URL completely defeats the point of it. Why do you think there is a distinction to begin with? It wasn't for lack of a good choice of syntax.   

       Some things you might want to think about:   

       - Passwords sent as POST data appearing in server logs and browser histories   

       - Large amounts of form data making URLs too long and getting truncated by some systems   

       - Leaking POST data via HTTP-referrer   

       etc
mitxela, Oct 30 2019
  

       Well, I suppose the distinction obviously is to separate the I/O as !/?, the MUTATE and FILTER types of queries. POST and GET. With GET requests we were supposed to FILTER/SEARCH the web entities, and with POST requests we were supposed to CREATE/MODIFY the web entities.   

       Regarding privacy/security, this would not suffer, as it would not appear in the logs, if implemented on the browser side as a convenience for user to use the ! to do POST requests.   

       However, that would of course break the consistency of the browsers, that we have, where whatever is in the URL, is just doing GET requests. Therefore, a different color (just like the HTTPS indicator) would have to highlight, whenever what is to be run, is a POST request. In addition, it would probably be great to simply let the browser users to have a consistent button or drop-down in the link, to choose, what type of request they want to make, without having to open developer tools.   

       Today, I suppose there exists an ambiguity such that, under legal circumstances, you can perfectly say that you opened a link, and saw a completely different content, because you made a POST request by opening it, not the GET.
Mindey, Oct 30 2019
  

       It shouldn't matter whether POST or GET is used since people use the back button a lot. Crappy websites break when you press the back button.   

       To manage state, all forms should include a ticket which is validated on the POST. Once the ticket is used, behaviour can be modified to enable the use of the back button. A couple of decades ago I used to use this technique to stop heavy searches being run multiple times
bigsleep, Oct 30 2019
  
      
[annotate]
  


 

back: main index

business  computer  culture  fashion  food  halfbakery  home  other  product  public  science  sport  vehicle