I was setting up a temporary WordPress site for a client as a placeholder for their business. All they wanted was their logo, a link to an existing product page, and a message about the site being under construction.
I was reminded a couple of days ago of the danger of using tools that help you to get things up and running quickly, by a question that I was asked in an interview. The question was pretty simple, but not something I’d thought about for a while, which was: “What are the verbs used in RESTful services?”.
Now intuitively I know that answer, but hadn’t really thought about it for a while, so I basically answered incorrectly (mostly because I suck at inteviews), only remembering that you do GET and POST in HTTP, so responding that GET is to query and POST is for inserts/updates.
Of course I know the reality (and one of the advantages) of RESTful services is that they behave by contract, so they can use the full complement of the HTTP verbs, and the convention is to use each one for a specific purpose:
- GET – used to get or retrieve a resource (always returns the same resource for the same query).
- POST – used to create a new resource (returns the location for the newly created resource).
- PUT – used to replace a resource (typically an update).
- DELETE – used to remove a resource
- OPTIONS – sometimes used to describe information about what verbs a service can use for a specific URI (not normally implemented however).
But the last few times I’ve done RESTful services, I’ve simply let an IDE generate them for me, so I haven’t even thought about those last statements. In the IDE, all I had to do was say I wanted to add REST (using Jersey) to my session beans, and voila, I have a full fledged RESTful service.
And of course on the consuming side, all I have to do is call the right method, and under the covers the Jersey client stuff does the right thing about which verb to use. So I’m not actually thinking about what’s under the covers, and because of that wouldn’t be quick on my feet about how the service is constructed under the covers.
There are of course pros and cons to approaching code in this way. In the early days of writing code, we all had to know what the machine language underneath looked like. Modern languages hid that complexity from us, and reading assembly language became a lost art practiced by rocket scientists and performance gurus.
By hiding the complexity we have been able to develop insanely complex applications that would not have been possible without those building blocks. Freeing ourselves with increasingly general patterns in code, we are able to focus on solving the problem at hand, and stand on the shoulders of those that go before us in doing so.
I don’t expect to need to write a RESTful service from scratch any time soon, but it is a good reminder that when you rely on tools to build your code, you are risking living with a lack of understanding of the underlying mechanism, which could make it difficult to know about the pros and cons of a solution.
I have a new open source project at VolunteerCake that is using their recently released web hosting service. This service includes the typical LAMP stack with MySQL, Apache and PHP, so I thought it would be a great place to keep a demo of the site running.
It was working fine, and then one day I noticed that the pages were being over aggressively cached. For instance, if I clicked the login button on the front page, and logged in successfully, I expected to see a “logout” button and my user name, but instead was seeing the original page. By hitting “shift-refresh”, I was able to get the right page to display, but obviously that wasn’t a good way to demonstrate the software.
During my work on figuring out my Plaxo problem, I found a really cool tool called Fiddler2 that acts as a web proxy and lets you do nifty things like see the headers on web requests. Using this tool, I was able to look at the cache headers being sent by the server which looked like:
HTTP/1.1 200 OK
Date: Tue, 18 Nov 2008 22:02:49 GMT
Set-Cookie: CAKEPHP=b7pvoorvj11tb45micnfqhc4b2; path
P3P: CP="NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM"
Expires: Thu, 20 Nov 2008 22:02:46 GMT
The part marked in red was the problem, the Cache-Control and Expires headers were being set to 48 hours in the future for my pages, so the browser was displaying the cached version of the page instead of asking the server for a new copy.
Knowing this, I opened a case with the SF.net support team to see if they could help figure out why the server was setting these headers for the PHP pages. I had a suspicion it had to do with the fact that Cake uses a new file extension of “.ctp” for the view files, but I really had no proof of this.
The SourceForge.net guys told me that their service had just been moved to some new servers, so it was possible this was related to that. They suggested that my application was responsible for setting the cache headers. While Cake does do some caching, it didn’t fit with what I knew. This exact same setup was working on my hosting service at http://volunteer.lctd.org/, which didn’t send those same headers.
I did some research on the Apache settings for cache, and while it is generally something you do at the server level, I found that it is possible to override these settings in the .htaccess file for a particular directory. Having had to tweak this file before to get Cake to work properly, my .htaccess file looked something like:
RewriteRule ^$ webroot/ [L]
RewriteRule (.*) webroot/$1 [L]
So what I needed to do was to tell the server not to set the Cache-control or Expires headers. After some experiments, I ended up with a new .htaccess file that looked like:
RewriteRule ^$ webroot/ [L]
RewriteRule (.*) webroot/$1 [L]
# Turn off Expires and set default to 0
Which basically turned off the whole caching on the http://volunteercake.sourceforge.net site. Since this is just a demo application, I figured that was good enough, so I didn’t spend any more time on figuring out how to restrict the change to a specific type of file (which would be important if this were a large application).