In a new post to his site Stefan Koopmanschap covers the creation of idempotent commands, that is, commands that can only run one at a time without having to worry about possible overlap.

One of the things you may run into these days (and that I had to solve this week) is that these days we provision all servers similarly (or according to their role). This may also mean that you provision several of your servers to run the same cronjobs at the same time. However, some tasks may not be run multiple times, and especially not at the same time. In a symfony project I'm working on, I was tasked with making sure some of the cronjobs would only be run once, even if started on several servers at the same time.

He then goes through the process he followed for adding in the locking making use of the console.command and console.terminate hooks in the Symfony Command component. He then made use of the arvenil/ninja-mutex package to do the actual locking. He works through his decision process on when to lock and how to detect which commands needed to be locked. He ends the post with the code for the listener to create and release the lock automagically when the command has finished.

Lee Davis has a new post to his site with some thoughts about RESTful APIS and the correct response to DELETE calls when a resource has already been removed. One camp says a 404 should be thrown as it's no longer there, the other says 204 a "No Content" should always be returned. Lee looks at both sides of the argument and shares some of his own thoughts too.

Recently I had a read of an interesting post by Lukas Smith (@lsmith) about the use of the DELETE method when building RESTful services. I wanted to get my thoughts down on this. Mostly to help myself, but if it helps you determine a better approach, then great. I’m nowhere near qualified enough to preach, so this is by no means a “you should do it this way / my way is correct post”, just food for thought. Besides, there are probably more questions here than answers.

He talks about the idea of "idempotence" when it comes to REST APIs and how it relates back to the DELETE discussion. He points out that the term has more to do with the end result of the request and not so much about how it's handled (and any "side effects" that may come with it). Various checks on the resource in question - like "does it exist" - could be considered a side effect of its operation. In his opinion, though, the 200 series of responses are more appropriate when a resource is actually deleted.