HTTPeasy0-2 years
A mobile client times out waiting for a response to `POST /api/orders`, so it automatically retries the exact same request. What could go wrong, and would the same retry be safe for `PUT /api/orders/42`?
It can go wrong badly for the POST: the server may have actually processed the first request and created the order — the client just never saw the response — so the automatic retry creates a second order for the same purchase. POST means 'do a thing' and is explicitly not idempotent: doing it twice is not the same as doing it once. PUT, by contrast, means 'replace this resource entirely,' and doing that twice with the same body leaves the same end state as doing it once — so retrying a PUT is safe in a way retrying a POST never is, purely because of what the two methods promise, not anything the protocol itself enforces.
PreviousSomeone writes a 'find the second-largest number' function by sorting the whole list and reading off the second element. It works, it passes every test with a small array, and it's noticeably slow once the list has a million entries. What's actually wrong with the approach, and separately — what's the general mistake in assuming the machine will 'figure out' what you meant for an input you didn't think about, like an empty list?Next A program that used to work now crashes somewhere in a thousand-line file, and nobody knows which recent change broke it. Someone suggests reading the whole file top to bottom to find the bug. Why is that the slow way, and what would a faster method look like?