The article is refreshing and makes clear that REST is violates KISS, making a good case for RPC with no nonsense on top of it.<p>I fully agree with that sentiment.<p>However, at some places the article goes over the top. This is really a pity, as those bits are not necessary for the overall argument. Moreover, those parts weaken the reading experience as much as a bunch of spelling mistakes would.<p><i>> Using “HTTP 404 Not Found” to notify about an unexisting resource sounds RESTful as heck, doesn’t it? Too bad: your nginx was misconfigured for 1 hour, so your API consumers got only 404 errors and purged hundreds of accounts, thinking they were deleted….</i><p>A non-existing resource doesn't mean it was deleted, but simply means it is not there - for whatever reason. Acting with deletion after receiving a 404 sound quite far fetched to me. (Except when mirroring, but then it would restore everything as soon as the configuration was fixed.)<p>Moreover, if the server does have active knowledge of the deleted status of a dataset, and wants to communicate that to a client, it would use 410 Gone. Only then the client has enough evidence to perform a deletion on their side.<p><i>> You want to use PUT to update your resource? OK, but some Holy Specifications state that the data input has to be equivalent to the representation received via a GET. So what do you do with the numerous read-only parameters returned by GET (creation time, last update time, server-generated token…)?</i><p>The PUT semantics only require it to be idempotent. That is, multiple identical PUTs should lead to the same result as a single PUT. The specs do not require that GET has to return the exact same value installed by PUT. Even more so, the specs actively discourage clients to make that assumption, as a different client - or any other event for that matter - could have changed the value in the meantime.