21–30 of 179 posts
All in all, I dislike the overall focus on the HTTP method when designing "RESTful" interfaces. If all we're building is, effectively, an RPC, why would the cacheability meta-information be the first thing we specify?
Earlier quoted context omitted.
My framework is already two decade old prior art and you still haven't actually convinced me that this RFC solves a problem.
1. Sometimes you need a request body. 2. POST cannot be guaranteed to be safe if re-sent. 3. This is GET with a request body, guaranteed* to be safe if re-sent. * With the caveat that it's only guaranteed if the server is following the RFC correctly.
For one you would never allow a client to dictate the query. That is a security and validation problem. So you have to deconstruct the query anyway and then rebuild it. That's HTTP APIs 101. Now if the authors of this RFC knew what they were doing they could enforce trust with some sort of JWT like trust mechanism but no they don't bother to define ANYTHING like that. Instead and I will quote this for completeness because it's honestly one of the funniest things I've ever read in an RFC.
> 4. Security Considerations
> It can be used as an alternative to passing request information in the URI (e.g., in the query component). This is preferred in some cases, as the URI is more likely to be logged or otherwise processed by intermediaries than the request content. In other cases, where the query contains sensitive information, the potential for logging of the URI might motivate the use of QUERY over GET.
This. This is just plain baffling to me. The argument is that QUERY replaces GET (it doesn't) so let's shove data into the same place that POST already does because it MAY MAY be logged. Bro the people doing the logging are logging the entire damn thing URI, Header, and Body. What even is this.
And again if they knew their shit they would know that GET has a soft cap of 2,083 characters from the internet explorer days so no one shoves more than that into a url for compatibility and if they do they risk losing data so they use POST anyway. Heck my framework even does JSON post bodies in the POST. And again if you are writing an RFC do your research and use this technical fact as an advantage. Define your own limits and explain why based on existing methodology. It would actually give your RFC some weight.
It doesn't even bother to address query feedback errors like what if the disk says no and writes are locked.
Frankly...... I miss the old days when RFCs where measured in pounds of paper.
> using HTTP GET with a request body is a bad idea, as for example users behind a corporate firewall or a different browser may be unable to use your website. So is using QUERY requests for quite some time from now.
So much simpler...
Earlier quoted context omitted.
1. Sometimes you need a request body. 2. POST cannot be guaranteed to be safe if re-sent. 3. This is GET with a request body, guaranteed* to be safe if re-sent. * With the caveat that it's only guaranteed if the server is following the RFC correctly.
I read the RFC front to back. It is lazy. To the point where I'd be embarrassed to even show it to people. For one you would never allow a client to dictate the query. That is a security and validation problem. So you have to deconstruct the query anyway and then rebuild it. That's HTTP APIs 101. Now if the authors of this RFC knew what they were doing they could enforce trust with some sort of JWT like trust mechani…
Every single SQL server allows a client to dictate the query. Furthermore, not all queries are SQL queries.
Earlier quoted context omitted.
I read the RFC front to back. It is lazy. To the point where I'd be embarrassed to even show it to people. For one you would never allow a client to dictate the query. That is a security and validation problem. So you have to deconstruct the query anyway and then rebuild it. That's HTTP APIs 101. Now if the authors of this RFC knew what they were doing they could enforce trust with some sort of JWT like trust mechani…
> For one you would never allow a client to dictate the query. That is a security and validation problem. So you have to deconstruct the query anyway and then rebuild it. Every single SQL server allows a client to dictate the query. Furthermore, not all queries are SQL queries.
What do you think people will make the Query request body? Most everything will use this for JSON but it could be anything so what other interesting things do you think will go in there? Query 1 + 1 and get 2?