In these days of new REST APIs every day I thought I go retro a bit: let's talk files a bit.
What?
I hear you say. Files are so twenty century!
Well, yes and no. Did you know that nine times out of ten you reboot your windows box, it's because the OS does is unable to delete a file? There are a variety of causes for this, all listed nicely here by Microsoft. The most frequent one is Culprit 2: the file is in use. That is why all installers advise to close all running applications first. But that does not work all the time, so after a timeout, Windows Installer decides that a reboot is necessary. After all, what can it do?
So, we have a system who's only way of dealing with a process opening files you need to remove/replace is a cold start in the hope that the very same process does not start running again! I bet that billions of dollars have been wasted because of that design (speaking from a mankind perspective - as consultant your mileage may vary).
Do we have something similar on the Web? Hard to say. The Web just starts implementing Write. Performing a DELETE while (many) GETs are in progress would be a similar scenario. Not a common use case as of today, but service implementors should beware. More problematic could be a (slow) PUT during busy GETs. Or even two interleaving PUTs where the second starts before the first is done.
Any system which sort-of locks internal resources during HTTP operation is doomed to repeat the past. Uh, the present. Windows.