Don't Use ENUM's, umkay?
Woah! Random blog post from the bitbucket... and it's very technical.
I can't reveal specifics of where I work or what I do - but I can say that I'm currently grappling with a massive change brought on by a decision somebody made a while ago that... well, I'm sure was a good idea at the time.
That decision? Put an ENUM in a web service interface. In my particular circumstance, the said ENUM is an identifier that tells the web service "who" is calling it. And in this case - I'm a new guy calling the service.
ENUM's are great when there's a specific set of allowed values you need to limit from your clients. It's almost like a built-in validation rule. Awesome! But when you put such a limitation on a service interface you wind up with all sorts of side effects. Like... what happens with the ENUM changes? Well - then everybody using the WSDL ends up changing.
Of course, I just tweeted "never use enums in a web service interface". I do hate making such blanket statements. NEVER and ALWAYS are very dangerous words.
But MAN OH MAN is it causing me grief right now!! I want to use a web service, but I'm a new client - and for reasons I'm sure were excellent and well thought out by the service-owners - one of the parameters I'm passing in is a client ID. And it's an ENUM. And I'm not in it. :(
SOOOOO - the ENUM needs to change. Ugh. Well that's a change to the interface. That triggers a build service. That triggers all sorts of changes to folks that ARE in the ENUM. And what value do they get in the WSDL change?
Nutt'n. Nothing. Zip. Zero. Zilch. It's money money money for reasons they don't care about. Why do they care that now I'M calling the service? They don't. But the corporate gears of change turn when the WSDL is changed.
Sure, existing clients don't have to update to the new service. But now the service owners have to maintain an old service version. Why? Because it's the one that DOESN'T have me. Value of doing that? Nutt'n. Nothing. Zip. Zero. Zilch. Money money money.
It's common theme in coding - especially when it comes to web services. There's this strange tug-of-war between flexibility and structure. I struggle with services that are so darn flexible I don't even know what they do. But then I hit the other side of things - like this problem here... Things that are so structured that a seemingly innocuous change turns into a massive hootenanny.
So don't use ENUM's in a web service interface. If you have a really GOOD REASON to do it - you're probably wrong. Even if you're not. You probably are. Don't do it. Make it a string. Deal with it in validation if you really really think it's important to restrict the values.