This is the third post in a four-part series about extending a simple Webmachine resource. The first part discussed adding support for the HTTP method PUT, and the second part added basic authorization, while the third part added conditional requests through ETag.
I can modify variables through PUT; how about removing them altogether with DELETE?
First a little sidetrack. While Erlang exposes os:getenv/1 and os:putenv/2, it does not expose an os:deleteenv/1. So, what I'm going to do instead is adopt the convention that a variable set to "nothing" (i.e. the empty list) has been deleted. This requires a little modification to resource_exists/2 to filter out variables with empty-list values. (See the full source at the end of this post.)
Sidetrack #2: I also noticed that there was a bug preventing values from containing the equals sign, so while hacking resource_exists/2, I fixed that as well.
With the empty-list-is-deleted convention in hand, I can implement DELETE handling like this:
I only want to allow one variable to be deleted at a time, so I'll modify allowed_methods/2 such that it only adds 'DELETE' to the method list if the request path is of the form /_env/VARIABLE.
I also want DELETE to require authorization, so I'll modify is_authorized/2 to watch for both PUT and DELETE.
And that's that. I can now use the following curl command to delete MY_VAR:
Before I get to the complete source, I want to take a moment to highlight something I stressed in an earlier blog post: Did you notice that none of the code I've displayed in the last few days has mentioned specific HTTP response codes?
The env_resource now runs all over the HTTP decision flowchart, returning everything from 405 when methods other than GET, HEAD, PUT, and DELETE are issued (or just the first three in the whole-environment case), to 401 when PUT or DELETE is attempted without the proper credentials, and 412 when ETags don't match on a PUT (or 304 when they do match on a GET!), and yet, I didn't mention a single code. I simply described the properties I wanted the resource to have, and let Webmachine do the translation.
I stress this because I think it's important to consider the power of an HTTP translation system. I've seen reduced development time as an effect of not having to worry about getting to the right response code in every corner case, while still adding necessary headers. I've also seen reduced troubleshooting time as an effect of being able to read through a resource that only concerns itself with describing its properties, rather than including a lot of mechanics for tearing apart HTTP requests and building up HTTP responses.
The Complete Code
Post Copyright © 2009 Bryan Fink