Thursday 2 August 2012

Resource identification is not a REST invention


An article on programmable web - pointed out to me by Fred Verheul (thanks Fred!) - gave me an adrenaline rush.
It was so full of bollox that I almost started to hyperventilate - which is a pun on the abundant use of the word hypermedia in that same post

Let me just quote one part of the post:

This subtle shift in the source of application control information makes it possible for the same client code to recognize and execute new features as they appear over time without the need for patches or downloads

The post contains more nonsense like this. Let me quote yet another brilliant piece, and be done with quoting:

Similar to the problem faced by system architects, developers lack the tooling for implementing hypermedia systems

Allegedly, what this author calls hypermedia systems hasn't been conquering every single IT system in the world because of missing tooling? Permission to laugh or cry please...

The piece praises the browser as a limited version of this ingenious contraption which enables the user to perform diverse tasks like banking and gaming with just the same browser without the need to download. Well excuse me, but all your browser does is continuously download - all the time

But let's leave the post for what it is, and address the issue at hand: changing functionality and function calls within a global IT system (which I think we can call the web, and many Enterprise applications - not to mention the average SaaS).
The basic problem is the evolutionary change aspect. We all evolve, change, grow - and everything around us. So does IT, and that is good - and bad. The bad part is where something changes that you don't want or need to change: in other words, there is added functionality or business value somewhere that you didn't ask for, yet because it now has changed and you are using it, you have to change your own implementation of it nonetheless - that is money thrown away, of course

That own implementation usually is a program that receives responses to requests sent out, and processes those towards or in the back-end. Loosely-coupled as anything might be, it is still coupled: the program you have written to couple with the outside world, is itself coupled to existing IT applications within its own landscape. Technically that might be loosely coupled, but functionally it is very tightly coupled of course

So that is why backward compatibility was invented. Backward compatibility basically means that whatever new functionality is added, you won't have to change your program unless you want to use it. Needless
to say, backward compatibility isn't a REST invention - it is a common problem in hich-tech and e.g. the IBM 7080 was introduced in 1961 because its predecessor, the IBM 7070, was not backward compatible at all with the IBM 705

So, you have to design and distribute new functionality in a smart way, in order to stay backward compatible. In IT, however, there is an additional issue: function calls change too, with added functionality.
I solved that problem by having each function have exactly one parameter: a by-reference object or array. But let me illustrate the issue first

OrderCar(Make, Type) is the functionality that let's you order a car. All you have to do is give make and type to uniquely identify one, and you'll be granted a brand new car. So, these two parameters (make and type) are mandatory.
Then, as it's not a T-Ford, the car salesman upgrades to a new functionality, enabling people to pick a coulour as well. Here is where the problem is at: the function call now has 3 in stead of 2 parameters, so everywhere you use the function, you'll have to change it from OrderCar(Make, Type) to OrderCar(Make, Type, Colour) - otherwise it won't be able to execute, regardless of which functionality you use - it will miss the third variable and simply cause your program to abort

However. In compliance with the rules of backward compatibility, the new parameter "colour" is optional, and in some programming languages you can make a function call parameter optional as well - in that case, you won't have to change a thing. The colour will just default to black, you won't have to change any function call, and there you go.
But if you're not the lucky owner of one of those languages, or have the new functionality reflected in a new URL, then you're toast. Hence why Roy suggested the concept of resource identification:

This abstract definition of a resource enables key features of the Web architecture. First, it provides generality by encompassing many sources of information without artificially distinguishing them by type or implementation. Second, it allows late binding of the reference to a representation, enabling content negotiation to take place based on characteristics of the request. Finally, it allows an author to reference the concept rather than some singular representation of that concept, thus removing the need to change all existing links whenever the representation changes (assuming the author used the right identifier).

Roy makes a case for backward compatibility on the web here: just don't blur the URL with version information or other attributes that (quickly) change over time. He could have just stated "You know, URLs aren't backward compatible if you include short-lived info like version numbers and such. So just don't" but a dissertation needs to be a certain size, and they aren't famous for being concise

Of course that doesn't solve the issue of actually having to change your code and back-end functionality, including front-end maybe, if you want to use that fresh new functionality. After all computer programs get designed and written by people, and are inherently static - and always tightly coupled to the back-end from a functional point of view. You can soothe some of the pain, but you can't make it go away

So, we have yet another person jumping the REST bandwagon with his own interpretation of REST.
The problem he addressed in the beginning?

When you have millions of users – each with an installed version of your app – every change that requires an updated download can result in lots of "unproductive" time

The result of the three companies that are trying out what he calls hypermedia?

These companies and others are adopting hypermedia as a way to improve the flexibility and scalability of both their internal and public APIs


Strong business case convincingly solved and case closed? Not in the very least...

0 reacties:

Post a Comment

Thank you for sharing your thoughts! Copy your comment before signing in...