3 ms·

Maybe it is, maybe it isn't. The nature of the web is changing, and has changed. Since GET requests can't have `body` data, if you have any hope of passing inf

Maybe it is, maybe it isn't. The nature of the web is changing, and has changed. Since GET requests can't have `body` data, if you have any hope of passing information along to a GET request, you must encode it in the URL in some way. This can be particularly important for things that contain unique but repeatable parameters that augment what you see on first load that would only be known by the consumer, and then can be shared by URL. For example, options set on a table you want to share with those options intact.

teddyh 3y ago
> Since GET requests aren't suppose to have `body` data, if you have any hope of passing information along to a GET request, you must encode it in the URL in some way. Or in the request headers.
- no_wizard 3y ago
  To be clear, I misspoke, I should have put effectively GET requests really can't have body data. Headers have the same problem. You can't possibly encode it without encoding it in the URL anyway
crazygringo 3y ago
For which something like a 4 KB limit is more than enough, like options on a table. The point is, once you switch from options to actual data, you switch from GET to POST. This is not a bug, this is a feature. POST is for posting data. GET is for retrieving it only, not for sending it.
- no_wizard 3y ago
  More than enough in your opinion. It is perhaps your use case that 4KB works completely fine for, but this is not everyones. We have a fairly complex set of options users can filter through (by design, and prior to its implementation, by high % of requests by users, FWIW) that need to be sharable on the GET request, they are definitely at least 12KB, likely more.
  - crazygringo 3y ago
    But that's far too large to easily share in things like plaintext emails or text messages. If you're unable to compress it further, why don't you implement a TinyURL-type scheme? Save the options on your backend and give them a pointer to the settings. And it can expire after 30d or 1y or never. Then it actually becomes the size of something shareable. URLs are resource locators. You're not locating a resource, you're passing a gigantic configuration payload.
    - no_wizard 3y ago
      This is true, but it is the most efficient way that doesn’t induce complexity like having to serialize every option chosen to the backend immediately. Knowing we can re-create everything in first request is much more simple than other methods and doesn’t require the end user to get a special link generated for sharing they can just share straight for the URL bar.
earthling8118 3y ago
Well there's certainly nothing that strictly prevents GETs from having a body other than no guarantee that all client libraries will handle them. I've seen a mix that allow it and disallow it. What is common is the libraries that don't support it don't seem to have any indication of this and from what I remember are likely to fail silently. Fairly annoying, so it makes sense why this is basically never used.

teddyh 3y ago

> Since GET requests aren't suppose to have `body` data, if you have any hope of passing information along to a GET request, you must encode it in the URL in some way. Or in the request headers.

no_wizard 3y ago
To be clear, I misspoke, I should have put effectively GET requests really can't have body data. Headers have the same problem. You can't possibly encode it without encoding it in the URL anyway

crazygringo 3y ago

For which something like a 4 KB limit is more than enough, like options on a table. The point is, once you switch from options to actual data, you switch from GET to POST. This is not a bug, this is a feature. POST is for posting data. GET is for retrieving it only, not for sending it.

no_wizard 3y ago
More than enough in your opinion. It is perhaps your use case that 4KB works completely fine for, but this is not everyones. We have a fairly complex set of options users can filter through (by design, and prior to its implementation, by high % of requests by users, FWIW) that need to be sharable on the GET request, they are definitely at least 12KB, likely more.
- crazygringo 3y ago
  But that's far too large to easily share in things like plaintext emails or text messages. If you're unable to compress it further, why don't you implement a TinyURL-type scheme? Save the options on your backend and give them a pointer to the settings. And it can expire after 30d or 1y or never. Then it actually becomes the size of something shareable. URLs are resource locators. You're not locating a resource, you're passing a gigantic configuration payload.
  - no_wizard 3y ago
    This is true, but it is the most efficient way that doesn’t induce complexity like having to serialize every option chosen to the backend immediately. Knowing we can re-create everything in first request is much more simple than other methods and doesn’t require the end user to get a special link generated for sharing they can just share straight for the URL bar.

earthling8118 3y ago

Well there's certainly nothing that strictly prevents GETs from having a body other than no guarantee that all client libraries will handle them. I've seen a mix that allow it and disallow it. What is common is the libraries that don't support it don't seem to have any indication of this and from what I remember are likely to fail silently. Fairly annoying, so it makes sense why this is basically never used.