The Dark Side of REST?

My organization is considering a move from a SOAP based SOA to a RESTful SOA. To be sure there are advantages and disadvantages to both, but I just encountered a problem with REST that I hadn't really pondered before.

I have used RESTful APIs before, but only to play with. I have messed with the Google Docs API using both REST (from Java and J2ME) and the Java libraries and done some other playing around. But I have never used a RESTful API in anger before. I have never really used one to solve a problem.

Well, I just did. And I found the experience unexpectedly enlightening.

The problem is a typical one for a geek like me. I recently got a book, Hamburger America, that has detailed reviews of 100 or so of the best hamburger places in America. Being a GPS owning geek and foodie I of course wanted to turn that into a custom POI file for my GPS so that I would always know when a truly great hamburger might be nearby.

I wanted to make sure I had a workable process before I spent a bunch of time typing in 100 addresses. So I grabbed the addresses of a bunch of highly rated burger places in the NE from the Phantom Gourmet and sent them to a couple of batch geocaching sites.

Alas, for whatever reason I got zilch. The stupid batch web geocaching apps don't do much in the way of user friendly error reporting. But they all use the Yahoo Maps API, so I figured I would simply write a little app myself if I thought it could be done in under 15 minutes.

10 minutes later I had a working Java Swing app that does batch conversions of addresses to latitude/longitude. That says a lot about the simplicity and power of REST, doesn't it? (It also says a lot about how easy it is to use Netbeans 6, but that's another post).

But the code I wrote was awful. Really horrid stuff. I hard coded everything that I shouldn't and I did the parsing without XML libraries using really basic String matching. It was easy and fast and it works great, but the tiniest change to the library and the whole thing will fall over.

Anyway, if you haven't guessed, the observation I made was this: it is extremely easy, to the point of being by far the path of least resistance, to write bad client code for a RESTful service. It is much easier to write bad code against a RESTful API than against a SOAP API (because the SOAP library, which is all but required, will do the heavy lifting for you).

We have our share of bad code lying about - we don't really need to be encouraging anyone to write more of the stuff. What can we do to prevent or discourage bad coding practices for RESTful APIs?

David

Crepes, crepes, crepes

I got a new crepe pan on impulse when I was in the mall the other day and I am extremely pleased with it.

For some background let me start by saying that I have been doing a lot of cast iron cooking lately, making me appreciate the qualities of a properly seasoned iron pan. So when I saw a DeBuyer crepe pan I was predisposed to fall in love with it. It is thin enough to heat fairly fast, small enough to aid in portion control, thick enough and made of the right material to heat evenly, light enough to be easy to manage for swirling batter, and simple and sturdy enough to last generations if properly cared for.

It is an extremely simple affair. A piece of punched out sheet steel with a handle spot welded to it.

I got it home and seasoned the crap out of it on the stove top. Before I ever used it I had it looking like something that has been around for decades. But boy does it ever work!

It outperforms the best non-stick cookware I have ever used. The crepes turn out perfectly time after time. The pan stays hot, so I can easily make crepe after crepe, factory style. I have never cooked a crepe before, but the first one I cooked was perfect, as was every single one since (so far at least).

The more I cook, the more I appreciate the simple tools that our grandparents used to cook with and the less I understand the fancy cookware that is so in vogue these days. You can't even buy a cast iron frying pan in a lot of otherwise well stocked kitchen supply stores. It is sad really.

My favorite crepe shop closed recently (across the street from MGH in Boston), but I think I will miss it a little less now. I will certainly have crepes more often.

David

Simon is getting press

I'm not sure how it is "gossip" exactly, but Simon is on PharmaGossip.

David

Dieting again

After a long break, I am back on the diet again (posts from last years efforts here, here, and here).

I have come to realize several things about myself through my weight control efforts. The main ones are probably that I am much better than most people about exercising iron control and I am much worse than most people about exercising reasonable control. Here's a graph of my weight over time:




As you can easily see, as long as I am paying attention there is a nice downward trend. The second I stop there is a nice upward trend.

So I have the iron control and the method. I am not worried about getting into my target range. But I am very worried about how to stay there once I do. I either need a better balanced strategy or I need to accept the idea that I am a yo-yo and I just need to be able to rapidly transition between good/not so good. I guess I'll spend the next couple of months pondering that.

Suggestions welcome.

David

Winner's Laws

A while back Alan Schoonmaker had an article in CardPlayer Magazine (Winners Are Brutally Realistic: Part II) in which he discusses his concept of four Winner's Laws.

These laws are brilliantly universal and I wanted to share them you. They are:

1. Admit that you overestimate your abilities and other virtues.
2. Admit that you have some unrealistic expectations
3. Get an objective assessment of yourself.
4. Select your games very carefully

Aren't they great?

I suppose that to be truly universal you have to restate the last one. Maybe something like:

• Select the opportunity that maximizes your expectation

Or maybe that is still too gambler-speak. How about:

• Select the opportunity that is most likely to produce either short or long term benefits.

For everything that I have excelled at I have (knowingly or unknowingly) followed these rules. For everything that I have not done as well at I haven't.

1. Admit that you overestimate your abilities and other virtues.

• Confident people are generally winners and expect to be winners, but confident people are insanely likely to be guilty of overestimating how good they are.
• If you overestimate how good you are you won't improve. You won't even try to improve. Pretty soon you will suck.

2. Admit that you have some unrealistic expectations

• You are a confident person. You expect to do well. But some of your expectations are ridiculous. Admit it. You aren't going to win the Nobel prize or cure cancer. You also aren't going to get a glowing review followed by a promotion every year.

3. Get an objective assessment of yourself

• You overestimate your abilities and you have unrealistic expectations. How can you possibly be objective about yourself? You can't. Find someone who can.

4. Select the opportunity that is most likely to produce either short or long term benefits

• Opportunities come and go. If you choose the one that is convenient, or the one that is most "fun", you are probably costing yourself.
• Either choose opportunities that have demonstrable immediate benefit (e.g. the job that pays better) or the opportunities that can have long term pay-offs (e.g. the project that will force you to learn something new that you expect to be useful in the future).

Hope you liked these.

David