Erlang, Yaws, and ETags

April 3rd, 2008  |  Published in erlang, REST, yaws  |  3 Comments  |  Bookmark on Pinboard.in

Regarding my “RESTful Services with Erlang and Yaws” article on InfoQ.com, Sam Ruby said:

This otherwise excellent article fails my ETag test.

When Sam speaks, I listen, so I’ve given his feedback a lot of thought.

As I wrote in a comment on Sam’s blog, the Erlang/Yaws RESTful services I work on do indeed support conditional GETs, so at least my day-to-day work passes his ETags test. As for the article, there are two ways to think about it:

  1. If you focus on the “RESTful Design” portion of the article, then yes, I could have added a “think about where you need to support conditional GETs” item to the “key areas to pay attention to” list.

  2. If you focus on the Yaws/Erlang aspect of the article, then keep in mind that dealing with ETags requires dealing with HTTP headers such as If-none-match and the ETag header itself. The article already shows you how to read request headers and write reply headers, though, and how you actually create specific ETag values for use in the headers depends on the particulars of your resources — Leonard Richardson’s and Sam’s excellent book already covers this pretty well.

I intended the focus of the article to be more about item 2 than item 1, so I think not specifically addressing ETags is OK.

One thing I should have included, though, is how to parse POST data. You use the yaws_api:parse_post/1 function for that, passing in an arg record. For typical form data, it’ll give you back a list of key/value pairs over which you can iterate, or from which you can extract expected key/value pairs using yaws_api:postvar/2 (or even proplists:lookup/2 or lists:keysearch/3, if you like). See the documentation at the Yaws website for more details, but all in all, handling POST data in Yaws is fairly trivial.

Responses

Feed
  1. Sam Ruby says:

    April 3rd, 2008 at 8:00 am (#)

    A non-hypothetical use case: syndication feeds. May require a non-trivial amount of processing to generate. May be polled relentlessly. May be polled by a large number of unique IP addresses.

    Any solution which avoids the computational overhead of computing the entire result before determining if the result has changed will scale better than one that does not. And structuring your application in such a way that you can do this is a considerably harder problem than correctly formulating and parsing the relevant HTTP headers.

    If you focus on this problem, then the need for an different web server to handle purely static pages is significantly reduced.

    That’s the conversation I attempt to elicit via this deceptively simple question.

    Meanwhile: thanks for the compliment and the plug for the book. :-)

  2. steve says:

    April 3rd, 2008 at 10:45 pm (#)

    Hi Sam: I didn’t pick up on the connection to the static page issue, but yes, I fully agree.

    I also agree that structuring an app to take full advantage of conditional GETs isn’t easy, which again is why I feel I couldn’t really have covered it effectively in that article. How one goes about putting such support in an application is highly dependent on the application’s resources and how their representations are computed. Nevertheless, putting conditional GET support in your application is well worth the effort, as the scaling benefits can be enormous.

    I’ll certainly continue to ponder this deceptively simple question, though. :-)

    And you’re quite welcome regarding my comments about your book. I think the thanks need to go in the other direction, though, as I use the book quite a bit, so thanks for that. :-) It’s a must-have for anyone doing RESTful development.

  3. Nodalities » Blog Archive » This Week’s Semantic Web says:

    April 17th, 2008 at 1:00 pm (#)

    […] RESTful Services with Erlang and Yaws, Erlang, Yaws, and ETag […]