REST-* can you please grow up

Well didn't Mark Little just thrown in a grenade today around REST-* by daring to suggest that maybe just maybe there needs to be a bit more clarity on how to use REST effectively.

As he said this "The REST-* effort might end up documenting what already exists which indicates that part of the challenge is that lots of people don't really know what REST is and certainly struggle as they look to build higher class systems and interoperate between organisations.

Part of this is of course about up-front contracts and the early v late validation questions. But part of it also appears to be pure snobbery and a desire to retain arcane knowledge which goes back to that "Art v Engineering" debate.

A few choice quotes from twitter

"Dear REST-*. Get a fucking clue. Atom and AtomPub already do messaging. No new specification needed, that's just bullshit busy work." - Jim Webber


"REST might lack clear guidelines, but something called REST-* with a bunch of vendors is hardly going to help!" - Jim again

"and if they think REST lacks guidelines for messaging/security/reliability/etc.., they're not looking hard enough" - Mark Baker

Now part of Mark Little's point appears to be that we need more clarity around what good should be in the REST world and this needs to be easier to access than it currently is. I've seen some things described as REST that were truly horrific and I've seen other bits in REST that were a superb use of that approach. The problem that all of them had was in learning about Atom, AtomPub how to use them, how to use MIME types and of course the balance between up front contracts and late evaluation.

Would it really be such a bad thing to have an effort that got people together and had them agree on the best practices and then have the vendors support developers in delivering against that practice?

The answer of course is only yes if you want to remain "1337" with your arcane skills where you can abuse people for their lack of knowledge of AtomPub and decry their use of POST where quite clearly a DELETE should have been used.

If REST really is some sword of Damocles that can cut through the integration challenges of enterprises and the world then what is the problem with documenting how it does this and having a few standards that make it much clearer how people should be developing. Most importantly so people (SAP and Oracle for instance) can create REST interfaces in a standardised way that can be simply consumed by other vendors solutions. It can decide whether WADL is required and whether Atom and AtomPub really cover all of the enterprise scenarios or at least all of the ones that count (i.e. lets not have a REST-TX to match the abomination of WS-TX).

This shouldn't be an effort like WS-*, its first stage should be to do what Mark Little suggested and just document what is already there is a consistent and agreed manner which vendors, developers and enterprises can agree on as the starting point and that this starting point would be clearly documented under some form of "standards" process.

Would that be a bad thing?

Update: Just found out that one of the two things that they want to do is REST-TX... its like two blind men fighting.

Technorati Tags: SOA, Service Architecture

Formalism over hacking - contracts, compilers and why engineering matters

At Uni I learnt Ada, in my first job I did Eiffel (and C) and in my second I did Ada (and C) as a result of which a bunch of people sent me a link to this article on how Ada delivered the sort of success that C programmers can only dream about. Udi Dahan then had a post over on InfoQ about how a "traditional" approach failed and required a much more engineering solution and some smart contracts.

Now I'm not going to say that Udi's project would have worked better first time in Ada (it wouldn't) but what it does highlight is something that Ada really helped people to focus on..... what is the range of acceptable results. Udi's project suffered because the expected range of data (tens) and the actual (hundreds of thousands) were so massively different.

The solution that Udi's team came up with appears pretty masterful and a great example of scaling a solution by looking at how the big clumps of data are actually assembled. By looking at the ranges and the manner in which they were created they were able to create a really great engineering solution.

Over on the Ada side the article highlights how Ada really upfronts the cost of development by making people really consider what is possible, what is probable and what shouldn't be allowed. By having these contracts it means that everything is explicit and this produces a greater focus on quality at those early stages of the project.

My experience with Ada was that it not only helped in ensuring this quality but that it really helped in ensuring the quality of the average developers on the team. Bluntly point an average developer in Ada was a productive member of the project, an average developer in C was a complete liability.

With all the talk of dynamic languages, scripting and late validation it is worth considering that when it really has to work it is always best to take an engineering approach and look at the contracts and ranges of information and to restrict the system to the correct handling of ranges rather than assuming that the system will be able to correctly handle everything.

As SOA becomes a standard way of operation and the issues of networked computing increase a focus on quality and contracts will become ever more important.

Technorati Tags: SOA, Service Architecture

In defence of design

There are some things that I thought had been accepted in Software Engineering as a good thing, one of these was that design time clarity around interfaces is a good thing and helps multiple teams work together more effectively. This however isn't apparently the case as Mark Baker has made clear in a recent InfoQ article

So what's the caveat? It's the issue of when the WADL is consumed. Some Web services proponents who have taken an interest in Web based solution have been using WADL as they would use WSDL, as a design-time artifact. Using WADL this way though, is akin to developing a Web browser with built-in knowledge of, say, the Google homepage HTML form at the time the browser was compiled: if Google changes the form in a backwards-incompatible way (i.e. not just adding a new optional parameter) after the browser is deployed, then the browser will not be able to use that resource/service. Using the hypermedia constraint with WADL means that the client should consume the WADL at runtime. So be careful when choosing your WADL tooling, as some tools that try to help you, don't.

Now I have to admit to being happy at seeing the growth of WADL in the REST community (next up they can deal with policy, reliability, security and other challenging topics) but the implicit suggestion here is that having reliable interfaces at design time is a bad thing and that its much more effective to have dynamic run-time only interfaces that can change, and which you can automagically (in a vendor sense) adapt to.
The problem here is that its one of those beguiling silver bullets, suddenly lots of things that have previously been a challenge will melt away by using REST and letting everything adjust at Runtime. The problem with this approach is that it is spectacularly difficult to engineer in complex real-world applications.

Put it this way, if you are implementing VMI between twenty vendors and a manufacturer do you really want each of those twenty vendors to have their own unique spin on stock updates and ordering, do you really want the manufacturer to change the schema for its stock report but only find out at runtime? Before we get the "late validation" argument again would you really bet a million dollars on an XPath getting the right value?

Its a wonderful theory around all of this dynamism and automatic change, but writing applications that have to dynamically adapt to schema changes and corporate policies. The last bit is a kicker...

if you're developing client-side code which makes assumptions which aren't true of all resources (or server-side "APIs" which requires this of clients), then you're not using the uniform interface.

Now I've argued before on the fact that things like Invoices cannot not be deleted (they can be cancelled, but that is not a deletion) while other elements (e.g. stock identifiers) can clearly be deleted. If you make an assumption that delete is valid for an invoice then you are a muppet... but you might be using a uniform interface.

Design time interfaces and contracts are a good thing, there are thousands of successful projects and programmes that testify to the fact. Wishing reality away doesn't change this.

Design is a good thing, engineering is a good thing, early agreement reduces back-end problems and the earlier you find the problems the cheaper it is.

Technorati Tags: REST

Engineering v Art the challenge of the masses v the talent

There has been more discussion recently around the contracts v late validation argument and Stefan Tilkov has a brief position around how the REST v WS links in and that thought that maybe these really were two different worlds that would never agree. I'm with Stefan, who is on the late validation side, that this is a big divide and is indeed something that has gone on in IT since I can remember.

Where I do disagree though is whether this is a good or a bad thing to have these camps. Now I'm clearly biased as I'm on the contract side but I thought I'd put the case as to why contract based and enforcement, and static languages, represent the engineering approach to IT delivery while dynamic languages and late validation is the approach taken by those who consider IT to be an art. This doesn't make the later inherently wrong, but it does mean that it is hugely predicated on the talent of the person doing the job.

This for me is the problem. When I used to do a lot of "proper" User Interface design there was often talk about the challenges of WILI v KISS. Everyone knows KISS, everyone recites it as an empty mantra, but most people end up doing WILI. WILI is "Well I like it" and is used as the rationalisation of lots of bad decisions, with UI design this was added to by the "well Microsoft do that" school of justification (which is fine if you are doing a word extension, but not if you are doing radar displays).

The same WILI and "appeal to authority" approach is part of the great Technology Delusion that runs straight through IT, part of the problem is simply one of talent. If I could have a team in support of Stefan and Mark Baker I'd have no trouble whatsoever doing REST, if I could have Larry Wall in support I'd be reasonably happy to have PERL code there and so the list of the truly talented goes on. Give me Dan Creswell in support and that Jini idea looks fantastic, hell I'd even say go for a massive project using Spring 1.0 if Rod Johnson had to maintain the XML files.

The appeal of dynamic languages to people who genuinely understand how computer systems should work is clearly appealing, as is pushing the bounds of technology and creating new and exciting ways that are just a little bit better than what came before. These are the people to whom IT is an art form, something that requires imagination and craft and to whom that improvement is important as they are trying to push the boundaries.

I've used dynamic languages, I mess around with them on my personal projects, but I never tend to recommend them on projects and indeed actively ban them when I am the architect.

So why do I choose to have strict contracts, static languages, early validation of everything and extremely rigorous standards applied to code, build and test? The answer was nicely highlighted by Bill Roth on his post around JavaOne Day 1, there are SIX MILLION Java developers out there. This is a clearly staggering number and means a few things.

1. There are lots of jobs out there in Java
2. Lots of those people are going to be rubbish or at least below average

But I think this Java groups is a good cross section of IT, it ranges from the truly talented at the stratosphere of IT down to the muppets who can't even read the APIs so write their own functions to do something like "isEmpty" on a string.

The quality of dynamic language people out there takes a similar profile (as a quick trawl of the groups will show) and here in lies the problem with IT as art. If you have Da Vinci, Monet or even someone half-way decent who trained at the Royal College of Art then the art is pretty damned fine. But would you put a paintbrush in the hand of someone who you have to tell which way round it goes and still expect the same results?

IT as art works for the talented, which means it works as long as the talented are involved. As soon as the average developer comes in it quickly degrades and turns into a hype cycle with no progress and a huge amount of bugs. The top talented people are extremely rare in application support, that is where the average people live and if you are lucky a couple of the "alright" ones.

This is why the engineering and "I don't trust you" approach to IT works well when you consider the full lifecycle of a solution or service. I want enforced contracts because I expect people to do something dumb maybe not on my project but certainly when it goes into support. I want static languages with extra-enforcement because I want to catch the stupidity as quickly as possible.

But most of all I restrict choices because the number of people talented enough to make them is vanishingly small I count myself lucky in my career because I've worked with some pretty spectacular people, but even in the best of cases it was around 10% of the project and in none of the cases did those people more into support. People will no doubt bleat that dynamic interfaces give some sort of increased flexibility, my experience however is that it just leads to a right pain in the arse which is a bitch to debug.

Unfortunately in IT the level of self-perception is not strong so far too many people think they are at the top table when in reality they should be left in the sandpit. This leads to people taking on dynamic languages, late validation, multi-threading, async and the like with a single minded belief that either

1. they will do this because Expert X said it was the right thing to do and they worship at the altar of Expert X and even when it sucks they will say "but X says its right so you are wrong"
   
2. They will do something because it looks easy and not understand the consequences
   

This is the reason I am against dynamic languages and all of the fan-boy parts of IT. IT is no-longer a hackers paradise populated only by people with a background in Computer Science, it is a discipline for the masses and as such the IT technologies and standards that we adopt should recognise that stopping the majority doing something stupid is the goal, because the smart guys can always cope.

IT as art can be beautiful, but IT as engineering will last.

Technorati Tags: SOA, Service Architecture