This weekend I had the opportunity to attend and speak at Symfony Camp UA in Kiev. This event was organized already for the 5th time and draws many developers from the region. While I did spend the entire week before doing an intensive Russian course in Odessa (just for fun, no Liip has no plans to open an office in Russia), I did my talk on REST in English. Next to mine the only other talk in English was delivered by Pawel, who spoke about Sylius. It was great to finally meet Pawel in person! At any rate all other talks were in Russian. It was semi possible to follow the Russian talks if the slides contained enough code but in the end I spend most of the time talking to people sitting on the comfy chairs in front of the conference room. There were two questions that came up multiple times, so I figure I also answer them quickly here.

DELETE and 404

I started my talk on RESTing with Symfony2 with an introduction to REST itself. On slide 7 of my talk I explained the concept of “safe” and “idempotent” HTTP methods. Many people were surprised when I explained that DELETE should be idempotent, meaning that sending a DELETE request to a resource that has been removed should infact not return a 404. However, after doing some additional research now, it seems like there is acually a debate on this topic. Personally, I think a 404 should only be returned in case the URI is known to be invalid. So for example if I know my URLs should look like /notes/\d+ and I get a DELETE request to /notes/foo then a 404 would be appropriate. Otherwise I think that a 204 is the correct response. The reason is that when I DELETE, all I care about is that the resource was removed. If I wanted to know if it existed previously, I would need to do a GET request (REST does not try to keep requests to a minimum). Now obviously there could be a race condition, but lets say I have read a resource, generate a UI an provide a “delete” button. When I click that button, do I really care if I was the one that deleted the record or if someone else already deleted it before me? If I would receive a 404, I would think that I constructed my URL incorrectly and that I need to check if the server changed the URL.

UPDATE: So there has been a lengthy debate on twitter following this post. First up it seems as if most likely idempotence in REST is limited to the results on the server and not to the actual response. Quoting wikipedia on this:

“Methods PUT and DELETE are defined to be idempotent, meaning that multiple identical requests should have the same effect as a single request (Note that idempotence refers to the state of the system after the request has completed, so while the action the server takes (e.g. deleting a record) or the response code it returns may be different on subsequent requests, the system state will be the same every time).”

In this sense it would no be a violation to return a different response status code for a deleted resource than for the request that actually triggers the delete. Now to make things fun, the German wikipedia entry disagrees. All things said, I still maintain that the points I raised above mean that most likely you want to return a 2xx code and not a 4xx. I would find a 404 highly confusing but in case I know for sure that the resource used to exist a 410 might be appropriate.

HHVM

Several people asked me about my opinion about HHVM. If I look back to the original announcement by Facebook for HipHop, then I have to say I was totally underwelhmed by their gains. Given all the effort and complexity getting twice the performance seemed like such a little gain, given that every single PHP 5 minor release has given speedup in the range of 20%. I felt that their time would have been better spend helping on those improvements and maybe writing a PHP to C-extension convert. Now HHVM is much more interesting because it at least gets rid of a lot of the pains of HipHop as it can be used in development more easily. In terms of performance the speed ups are mostly for longer running computation heavy requests otherwise they are quite small compared to PHP 5.5 with OpCache. The memory footprint reductions are however quite significant even for requests that do not do a lot of number chrunching. What makes HHVM really interesting is that they are just at the very beginning of adding optimizations to their JIT. So there seems to be the potential for significant further speed ups in the near future. So given that HHVM now runs with many popular frameworks and libraries we are certainly keeping an eye on HHVM. We will hopefully soon publish a blog post with some more details on our performance analysis of HHVM.