3 ms·
Not freely. It is idempotent, not safe. So it still can have serious load consequences.
by spockz 4mo ago
Not 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.
- themgt 4mo agoGreat, got it. I'll update my running "how computing works" chart with this new information: | implementation = reality | magic | |-----------------------------------| | 999,999,999,971 (+1) | 0 |
- spockz 4mo agoWhy the snark? The existing methods have been around for ages. Many engineers I’ve encountered were not even aware that there was a distinction between “idempotent” and “safe” as attributes of a method and generally conflated them, using “safe” in the sense of the dictionary definition instead of the spec’s. Elsewhere it was suggested that we can now replace POST with this query. I was trying to be cautionary because just changing the method alone will bring different behaviour. I did so in brevity because I was in a rush. IMHO, that does not call for snark.
- spockz 4mo agoYes. That is what the spec says. However, if the search query is expensive you need some form of caching. Either on the endpoint itself caching the data, or the mechanism with location to redirect to the location of the result.