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:

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.

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.

I think it’s one of those articles that could be much, much longer and far more detailed if space (and time) permitted, but hopefully there’s enough there to whet your appetite if you’re considering developing RESTful web services in Erlang. I really can’t say enough good things about using Erlang and Yaws for this purpose — it’s quite a solid platform.

I’ll be giving a talk on the same topic at both JAOO Brisbane and JAOO Sydney at the end of May and beginning of June, respectively.

Either it’s suddenly become 2004 again, or somebody didn’t get the memo. It’s hard to choose where to begin with this one — hmm, maybe this little tidbit:

Now here’s the absolute coolest part (at least in my opinion). Armed with the WSDL document, you can use freely available, open source tools to automatically generate stub code to send requests to and receive responses from the SOAP web service in just about any modern programming language of your choosing.

For both the client and the server.

The stub code generates and parses all of the XML. As a developer working in the language of your choice, you are completely abstracted from the sending and receiving of data on the wire.

In my Jan/Feb Internet Computing column, Serendipitous Reuse (PDF), I talked about interface coupling and the benefits of REST’s uniform interface constraint. I find that whenever you discuss that topic, though, REST detractors tend to say, “Well, you’re just pushing the coupling problems to the data.”

The problem with that assertion is that it assumes coupling is a fixed constant — if you eliminate it from one point, whatever you’ve gotten rid of just has to pop up somewhere elsewhere, like some sort of strange “Conservation of Coupling” law. Of course, that’s not true. In my latest column, Demystifying RESTful Data Coupling (PDF), I turn my attention to this claim and explain how RESTful data works, and why it too, like RESTful interfaces, reduces coupling when compared to WS-* and other similar approaches.