Steve Vinoski’s Blog

My Nov./Dec. Internet Computing column is now available. It’s entitled “RESTful Web Services Development Checklist“ and as its name implies, it covers some of the primary areas developers need to focus on to write good RESTful web services. These areas are:

• Resources and their URIs
• Applications and Hypermedia
• Representations and Media Types
• Methods
• Conditional GET

Regarding the “Applications and Hypermedia” area, I feel Roy Fielding’s pain that many efforts labeled as being RESTful seem to completely ignore the hypermedia constraint. I believe many developers tend to miss this constraint because they’re so used to using libraries and frameworks that offer lots of entry points, and having knowledge of those entry points in the client normally isn’t that bad since the client and library/framework are tightly coupled into the same address space anyway. In a distributed system, though, this definitely does not hold true; when the client knows a bunch of entry points into the service, it ties the client to that service and inhibits their independent evolution.

Anyway, please read the column and let me know what you think, and thanks again to Stefan Tilkov for his helpful review of the draft.

Coincidentally I also feel Roy’s pain when it comes to writing about REST. He states:

I don’t try to tell them exactly what to do because, quite frankly, I don’t have anywhere near enough knowledge of their specific context to make such a decision.
…
So, when you find it hard to understand what I have written, please don’t think of it as talking above your head or just too philosophical to be worth your time. I am writing this way because I think the subject deserves a particular form of precision. Instead, take the time to look up the terms. Think of it as an opportunity to learn something new, not because I said so, but because it will do you some personal good to better understand the depth of our field.

Exactly.

Obviously, Roy is the ultimate REST authority, given that he defined it, so I’m not at all claiming to be anywhere near as authoritative about it as he is, yet I’ve also experienced what he says above. For example, consider this informal review of my columns I received a few months ago in a comment on someone else’s blog:

The articles of yours that I’ve read are…amorphous to me. They speak in generalities. I haven’t read an article where you sit down and write the same service using both REST and RPC and compare the two. When you speak in generalities, we can’t objectively evaluate any of the specific trade-offs between approaches… Arguments that happen at too abstract a level can’t go anywhere, because our positions aren’t specific enough for anyone to evaluate anybody else’s claims.

In other words, “since your columns don’t do my thinking and experimentation for me, they’re useless to me.” Hmm. Maybe I’m just old school, but I’d much rather understand mathematics than require someone to hold my hand while I blindly punch buttons on a calculator. In other words, as the old proverb goes, I’d much rather try to teach you to fish so you can feed yourself. As I state in this new column:

Whether developers of RESTful HTTP-based services write their code in IDEs or with simple text editors, and regardless of which programming languages they use, they must understand REST and HTTP fundamentals to succeed.

If you’re writing RESTful web services, you need to be able to parse HTTP Accept and Content-type headers. The Accept header tells you what media types the client can handle, and Content-type tells you what the client is sending when it invokes PUT or POST.

Several years ago Joe Gregorio wrote a really nice article explaining how to properly handle such parsing, and he implemented his ideas in the form of the mimeparse Python module. Later, others added Ruby and PHP versions.

In my Erlang web services work I’ve been doing just enough to parse my Accept headers, knowing full well my approach had holes in it and would eventually need to be done right. When I recently stumbled on Joe’s article and code, I decided to port it to Erlang and use it. Joe’s code is very clean and has accompanying unit tests, so the port was pretty easy. However, in the process of plugging it into my system I found a reasonably common case where the best_match function would return a wildcard match in preference to an exact match, so I added unit tests for that case and repaired the problem for all four languages.

I also found that Java’s URLConnection class, or maybe it’s HttpURLConnection, sends a plain “*” as a wildcard MIME type, which I don’t believe is legal (please correct me if I’m wrong), but since I figure there’s probably more than a few clients out there based on that code, I modified the four mimeparse implementations to handle that as well, treating it as “*/*”.

All four implementations are available from the mimeparse project home page.

My latest Internet Computing column has been available since last Friday. It’s entitled “RPC and REST: Dilemma, Disruption, and Displacement” (PDF, HTML) and like my previous 2008 columns, it explores another angle of the “RPC vs. REST” debate.

Since previous columns have covered many of the technical angles, this time I present the debate from the technology adoption angle. As the abstract for the column says, many technologists tend to treat such debates as if they’re purely technical, but of course they’re never that black-and-white. What’s often behind some of the raging “technical” debates we’ve all seen or experienced is simply the difference between the arguing parties in their relative positions along the Technology Adoption Lifecycle curve. Nobody would be surprised at a disagreement over technology between someone classified as an early adopter or visionary (from the far left of the curve) and someone classified as a technology skeptic (from the far right), yet we always seem surprised when two people whose preferences aren’t too far apart on the curve — from the opposite edges of the mainstream band in the middle of the bell curve, for example — don’t see eye to eye, despite the fact that this sort of scenario is quite common. Even small differences in goals for adopted technologies and desired risk/reward trade-offs, along with the inevitable hidden and unstated assumptions resulting from such factors, can cause vigorous debate about what technology or approach is best for a given situation.

When it comes to published explanations of how innovation works and how technologies move along the adoption curve, my favorite author by far is Clayton Christensen. IMO all developers should study and learn from his books, specifically The Innovator’s Dilemma, The Innovator’s Solution, and Seeing What’s Next. All are amazingly insightful works that will open your eyes to how real-life markets react to technological change and advancement.

In this column I try to view and classify the “RPC vs. REST” debate based on Christensen’s theories about innovation and technology adoption. I hope you find it interesting, and as always, I welcome all constructive comments.

I’ve noticed that frequently in technical discussions, the strongest disagreements seem to come from people with little to no actual experience with the technology they’re arguing against. How can that be? For example:

• Test-First Development. I wish I had a dollar for every time I’ve suggested to a developer that writing their tests before or along with writing their code will make the code not only easier to write but also more robust coming out of the gate, and I get back responses like, “What? That’s crazy! How can you write tests before you have any code? That doesn’t make any sense!” Having an initial reaction like that isn’t such a big deal, as I’ve seen numerous developers who have such reactions actually try the “test first” approach and quickly become strong advocates who wonder how they ever did without it. The point is, though, that they actually tried it. Arguing with them before they tried it always turned out to be a total waste of time. No amount of words seemed to convince them. They had to experience it before they understood it.

• Erlang syntax. Erlang is getting more and more attention these days, and rightfully so, but a typical reaction from those who have written little to no Erlang code is that the language’s syntax is too weird, too hard to read and write, etc. Is the syntax different? Yes. Is it weird or difficult? No, not at all — in fact, it’s actually very simple and regular when compared to popular general-purpose imperative languages. Spend a day or two writing some real Erlang code, and I guarantee you that any initial dislike you might have for its syntax will disappear.

• REST. If you search the blog of any REST proponent, including this one, you’re sure to find all kinds of comments from detractors who argue against REST despite never having used it to develop any real systems. Similarly, the blogs of many WS-* advocates who have never tried using REST contain all kinds of reasons why REST can’t possibly work. Check out the comments in Damien Katz’s recent “REST, I just don’t get it” posting, for example; you have useful ones from those who have obviously used REST and understand its benefits, and then you have other comments that argue against REST while simultaneously showing a great misunderstanding of it. Those detractors would do well to read Bill de hÓra’s excellent response.

Also interesting about these three particular cases is that I don’t personally know of anyone who’s actually tried the approaches and decided against them. In a posting last November, for example, I asked for comments from anyone who had actually tried REST for real and with an open mind, but decided that it was inferior to WS-* and so abandoned it. Either nobody read that posting or no such people exist. I’m fairly confident it’s the latter.

There will always be arguments made by people whose livelihood is somehow threatened by the approach they’re opposing, but I don’t think that’s the source of all the opposing arguments. As developers we can’t possibly try everything, of course, because there just isn’t enough time. It’s inevitable that we’ll sometimes have to resort to researching an approach via only reading, questions and discussion and decide against it without prototyping. But ultimately we developers owe it to ourselves and our employers to keep ourselves objectively informed so that we can take advantage of new approaches whenever appropriate. When a whole bunch of smart developers have success with a particular approach, I don’t see how any responsible developer can actively and vocally oppose it without first objectively trying the approach and experiencing it firsthand.

Eric Newcomer gives us his take on my recent articles (1, 2, 3, 4) and blog postings (1, 2, 3, 4) about RPC, REST, and programming languages:

Anyway, after carefully reading the article and blog entries, I believe Steve is not against RPC per se. He wants people to think before just automatically using it because it’s convenient.

Exactly!

Also spot on are the following postings:

• Bill de hÓra: Patterns of Web Architecture
• Three postings from Stu Charlton:
  • Convenience, Correctness, and Network Interactions
  • Can technology progress?
  • On changing industry mindsets

The beauty common to all these postings is the breadth, depth, and variety of thinking and reasoning they present. There’s a lot to read, but if you’re interested in critical thinking about the design and construction of distributed systems I encourage you to read them all the way through, including the comments, and to follow the links they offer as well.