Walkscore
First via James Robertson, then via Joel Spolsky, I ran into walkscore.com. It seems like a relatively interesting page. My current home rates a 25, which seems a bit high, though I do walk or bike a fair number of places. You can walk to the grocery store or coffee shop if you're energetic (it's about 2 miles), the elementary school my daughter goes to is just under a mile - at age 5, she can ride her bike that far. My old neighborhood is an 88; which seems about right. There, the closest supermarket is 5 blocks, and the liquor store and coffee shop are a block away. if you're energetic, you can walk to the central branch of the public library and the Denver Art Museum, and 2 or 3 of the top restaurants in Denver are an easy walk.
I'm a bit surprised that Walkscore seemed to come up with reasonable scores, looking at the locations they used to build the model, very few of them are actually places I frequent. Walkscore's big issue is that it doesn't consider political boundaries at all, which makes the school calculation way off in my area. The closest school to us is in Aurora, and since there is no right-of-way open between Moline St and Central Park Blvd, the actual distance you have to cover between my house and Fletcher Elementary is considerably further than half a mile. There are numerous examples of this - Montview Blvd and Colfax Avenue have a large number of businesses, but getting down there requires a big detour. Even if you allow for the assumption that one would be walking, the southern boundary of Stapleton on the East side of Westerly Creek is largely private property and industrial, which means that you'll need to scale a few fences to do that walk.
I suspect Walkscore is a good model in urban environments, not so much in suburban environments, and seems to work especially poorly for areas near boundaries between municipalities.
— Gordon Weakliem at permanent link
How I Stopped Worrying and Learned to Love the Web
I've read a few testimonials lately, notably from James and Dare, roughly along the lines of "how I stopped worrying and learned to love the web". Unlike Dare and James, I lived with a WS-* application day to day for about 3 years. I got into SOAP and WS-* via Galileo Web Services. It mapped nicely to Galileo's existing XML Select product and solved the major barrier to adoption for XML Select; namely, that it was a Windows-only product and some potential customers did not use Windows.
Ultimately, there were a number of problems with GWS. First, this was in the 2001-2004 timeframe, relatively early in the development of WS-*, so we ran into many of the early adopter problems. Second, while it seemed that Document/Literal was the way to go with our services, it became clear pretty quickly that Doc/Lit was not well supported outside of the .NET and Java stacks, and while one of the big benefits of SOAP was supposed to be code generation as enabled by WSDL, the code that was generated was difficult to understand. Also, at least in the .NET framework, it turned out that there were several things left out of the generated client stubs that turned out to be best practices - changes that allowed us to generate less network traffic, but required modifying the generated proxy code. In the end, we ended up having to write client libraries for several of our customers.
In my current job, one of our partners exposes a service that requires authentication via WS-Security, either using X.509 or a User Token. Interfacing to these services is quite difficult, in my experience. Sometimes, this is the fault of the stack sending vague error messages. Ultimately, while the security story is touted as an advantage of the WS-* technologies, I'm not convinced that there's any advantage to WS-Security, given the difficulty of implementation. Given that, I can't imagine the codegen situation gets any better with WS-Security.
There's a central engineering principle that led to the decision to go with SOAP in these situations: the need to know the correct answer, right now. Caching is often a scary thing for implementers, particularly downline caching. It's hard to get your head around the idea that caching is not only good, it's essential if you want to reach really huge scale, and caching on the server is not going to get you all the way, you're going to need some help from the network.
I am getting a little tired of the "REST is hard because there's no architectural guidance". Dare sums up the answer pretty nicely. Read the articles, buy the book, learn from others' mistakes... and from the good designs as well. Incidentally, this last point is one of the real strengths of the Richardson/Ruby books: they spend quite a bit of time analyzing what's wrong with some of the services that are popular but not well-designed.