4 ms·
> It also implies an unbounded and user-controlled cache key, The query part of GET's URI is also barely bounded in practice and user-controlled, and is indeed
by Joker_vD 4mo ago
> It also implies an unbounded and user-controlled cache key,
The query part of GET's URI is also barely bounded in practice and user-controlled, and is indeed used as part of the cache key (because it's a part of URI), so I am not sure why you raise this objection at all.
- giancarlostoro 4mo ago> and user-controlled I've found some sites that tack on a session ID and if you try to tamper with the URL in any way, it sends you back to "Page 1" really annoys me lol at that point let me skip to any page with your web UI.
- PunchyHamster 4mo agoWell, because it is more code. Current caching software caches by headers + query string. It now needs to be expaned to cache by body too. It feels very pointless and there is no drawback of just using POST
- afavour 4mo agoIs caching not the primary reason to use this over POST? You should never want to cache POST requests.
- drdexebtjl 4mo agoNo. Being idempotent, it also lets the browser/client/reverse proxy retry it if it fails.
- nfw2 4mo agoTechnically a put or a patch is also idempotent. The benefits are idempotent and safe (and semantically appropriate). Post (generally) communicates something is changing whereas a query doesn't
- gamache 4mo agoPUT is idempotent, PATCH is not always. The semantics of a PATCH payload are up to the server and standards like JSON Patch (RFC 6902, https://datatracker.ietf.org/doc/html/rfc6902 https://datatracker.ietf.org/doc/html/rfc6902) allow non-idempotent operations like adding an item to a list.
- nfw2 4mo agoI stand corrected although using patch this way seems goofy to me.
- OvervCW 4mo agoThere is: your browser or other type of client does not know it can repeat a POST request if it fails, whereas a QUERY request can be freely repeated in case of errors.
- spockz 4mo agoNot freely. It is idempotent, not safe. So it still can have serious load consequences.
- Joker_vD 4mo agoUnlike POST, however, the method is explicitly safe and idempotent, allowing functions like caching and automatic retries to operate.
- account42 4mo agoPutting something in a spec does not automatically make it true. In the real world if you repeat expensive queries more than an undefined amount you get blocked or at least bot-checked.
- projektfu 4mo agoFrom the browser POV it doesn't need to ask if you want to re-send data.
- themgt 4mo agoPutting something in a spec does not automatically make it true. Terrible news for computing.
- spockz 4mo agoThe point is that you need to take care to make the implementation of that endpoint safe. It isn’t safe magically by itself.