Learning from examples alone is fundamentally flawed. It’s like trying to define the laws of physics based on empirical evidence alone.

One of the best teachers I ever had was a gentleman named Dr. Van Hatz, who taught some of the math courses I took for my BSEE, such as Differential Equations. He began each class with a humorous story of some sort — he was a very well traveled guy and had lots of stories to tell about his trips. He’d then show us the theory of whatever it was he was teaching us that day, and then run through some examples. It was all so clear. If he had shown the examples first, or stuck only to the examples, it wouldn’t have made any sense. Everyone who had to take the courses he taught tried to get into his classes rather than take them from any another teacher, because they all knew they’d have the best chance of learning the material from him.

It’s always best to provide both theory and example if you can, but if you can do only one or the other, due either to space limitations (like my columns) or time limitations (like some presentations), I generally lean toward theory, because that’s the foundation. Like I said in an earlier comment above, it’s usually easy to find examples on the web, so if you understand the theory then you can make sense of the examples, but not necessarily vice versa.

Yes, I know there are people who don’t like this approach — some have already commented here, in fact — but you can’t please everyone.

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.

I once did a presentation on REST. I wanted to share the understanding I gained by asking Roy (after reading his thesis) so many questions that he had the patience to answer. I didn’t claim to be an expert.

I tried to show how Roy derived REST starting from the Null Architectural style and adding constraints one by one and how it induced certain properties and what were the pros and cons. The goal was to create an understanding/appreciation of principled design in general and also on the impact of imposing or relaxing a constraint.

It seemed that most in the audience wanted a quick fix. Very few seemed genuinely interested in understanding the fundamentals behind it. Majority wanted specific examples on how to do a shopping cart etc.. or knowing how they could apply REST to their current environment/project. The following comment I received in my speaker evaluation sort of summerized it.

He spend quite a bit of time explaining REST, but didn’t talk about concrete examples. The other speaker covered these points in 5 mins and moved to more concreate examples of using HTTP

Maybe I took the wrong approach and was one of those boring types who talks more theory. I am from a math background, and what I learned from a young age is that if you learn the theory/fundamentals behind a concept properly, then you can apply it to any given situation.

Regarding your second point, I think most REST developers, say those on the rest-discuss list for example, understand that it’s not a black-and-white issue. I think Roy was simply pointing out that people are starting to market services and applications as being RESTful when they’re clearly lacking in that regard.

The thing is, if you can’t call yourself RESTful even though you’re RESTlike, you lose out on a lot of usable vocabulary and implicit understood patterns when describing your API, framework, application, etc. Following me?

For example, saying something like JAX-RS isn’t a RESTful framework because it doesn’t have facilities to easily support HATEOAS is just counterproductive to the whole movement. (I’m not saying you said this, but I’m just giving a for instance…)