It’s amazing to me the attention and outrage expressed against Bill Belichick and the Patriots for Spygate when there’s much more serious cheating going on in the NFL.  I mean, Belichick gets lynched for taping a team to figure out its tendencies.  A practice that I sincerely believe Belichick thought was a grey area in the rules.  Anyways, that’s what coaches are paid to do, analyze film to gauge a team’s tendencies.

In comparison, we have a multitude of other teams tampering with free agency.  For example, the 49er’s were recently penalized a 5th round draft pick for tampering with the Bear’s Lance Briggs in free agency.  The quality of players (or lack thereof) has a much more dramatic affect on the outcome of a game than whether or not a coach can crack an opposing team’s defensive signals.  How about the Patriot’s 2006 season?  Remember the Dion Branch fiasco when the Patriots were basically forced to trade their best receiver away at the beginning of the season?  Where was the outrage, outside of New England, when the Jets tampered with Dion Branch?  The 2006 AFC championship game against the Colts was so close one play could have changed the outcome of the game.  Ya think having Branch would have made a difference?  No, not at all  ;).

It doesn’t stop with free agency tampering.  Numerous teams have also violated the salary cap.  Those same 49ers were penalized $400000 for violating the cap in Steve Young and Brent Jone’s contracts.  The same Steve Young who lambasted Belichick and the Patriots on ESPN.  Its not just the 49ers.  The Broncos were penalized, not once, but twice for salary cap violations.  The first was in regards to John Elway’s contract.  Should the Broncos also have an asterix next to their superbowl victories?  Where was the outrage?   Spectre, where are you?  Oh, I forgot, you’re a senator from Pennsylvania, not one from Georgia or Wisconsin.

All and all, I’m fine with the Patriots getting punished by the commissioner.  What I’m not fine with is the Patriots being treated as a special case by the media and the fans.  I want to see equal outrage against other teams that violate the rules, equal press coverage.  Its only fair that fans in San Francisco, New York, and Denver experience similar humiliation and witch hunts.

A great article by Stefan Tilkov on Addressing doubts on REST.  This and his previous article are a must read for any REST noob.  I wish I had them available when I was researching REST almost a year ago.

I recently ran into the situation where I wanted to do lazy, on-demand, initialization of a registry. In previous applications, I would just use get()/put() from java.util.ConcurrentHashMap because I didn’t care if something was created more than once accidentally as it would eventually, and quickly, sort itself out and all I’d lose is a tiny garbage collection. Unfortunately, in my current project, a registry entry cannot be allocated twice as two different versions of it might be used concurrently and each registry entry holds and maintains state. These resources need to be individually unique. Thankfully, java.util.ConcurrentHashMap has a nice method called putIfAbsent(). This method does the atomic equivalent of:

if (!map.containsKey(key)) {
   return map.put(key, value);
} else {
   return map.get(key);
}

So, what I can do is do a mini double check. When I lookup at entry, if it doesn’t exist, allocate a temporty version of it and call putIfAbsent.

public V get(K key) {
   V value = concurrentMap.get(key);
   if (value != null) return value;

   value = new Value(...);
   V tmp = concurrentMap.putIfAbsent(value);
   if (tmp == null) {
      return value;
   } else {
      value.cleanup();
      return tmp;
   }
}

If putIfAbsent returns null, then I know nobody has created a version concurrently.  If it doesn’t return null, then I know somebody has initialized this entry concurrently.  In that case, I cleanup the created value, and return the one already in the registry.  This looks a lot like the double-check-nono, but it actually isn’t as ConcurrentHashMap performs the putIfAbsent atomically.

I’ve been playing around a little bit with the idea of creating a RESTFul MOM/ESB where the client requests a specific format and the server transforms the content if it can. For an ESB, this usecase would normally turn up for various XML-based messages and documents. The client would request an XML document of a certain schema and the ESB would return that format, performing a transformation if applicable.

For a RESTFul ESB, I’d want to use HTTP content negotiation. The problem is, AFAIK, there is no standard MIME type, other than “application/xml”, that allows you to specify an XML format with schema information. Being a REST noob, I emailed my friend Steve, a REST enthusiast, and asked him if it would be ok to embed schema information into the media type. My first thought was the media type would be:

application/myschema+xml

Steve’s response was you can’t just make up a MIME type on your own and expect it to work well on the Internet without registering it. At first I thought, what’s the big freakin deal? But then I realized, what if you want to point your browser to a message in a remote RESTFul queue and just view its content? If you use “application/myschema+xml” your browser ain’t gonna understand it.

So, I decided to do a search on “decentralized mime types” and came across a few blogs from Stefan Tilkov, Dan Diephouse, and James Strachan. Here’s a summary (sorry if I left out anything)

Use AtomPub

One idea was to use AtomPub . I don’t like this idea at all. One, I just want to send a bloody XML document! KISS baby KISS! Second, if I’m going to use an envelope format, why not just use SOAP and WS-*? (no thanks). This, IMO, sort of defeats one of the general principles of REST.

Define a new decentralized MIME type

The idea would be to define a decentralized MIME type like this:

application/data-format;uri=http://mediatypes.example.com/foo/bar

The uri would point to something like an RDDL document that defined the real format. Beyond KISS, what I don’t like about this approach is that again, I have no way of pointing my browser (or some other generic client) at the resource and just viewing it.

Use MIME properties

I saved the best for last. The final idea was to embed format information within MIME properties:

application/xml; schema="http:/..."

application/octet-stream; data-format=java

Use a registered MIME type, but append extra format information as a MIME property. I did a test on this with Firefox and Safari and it doesn’t screw up the viewing. So for me, MIME properties it is! I would be interested in links to other thoughts on this.